Re: [PATCH v5 02/18] iommu: Implement IOMMU Live update FLB callbacks

[Nicolin Chen]

On Sat, Oct 10, 2026 at 03:18:11AM +0000, Samiullah Khawaja wrote:
> On Tue, Oct 06, 2026 at 04:31:01PM -0700, Nicolin Chen wrote:
> > On Mon, Sep 21, 2026 at 12:48:18AM +0000, Samiullah Khawaja wrote:
> > > +struct iommu_flb_obj {
> > > +	struct mutex lock;
> > > +	struct iommu_flb_ser *ser;
> > > +
> > > +	struct iommu_hw_array_ser *curr_iommu_array;
> > > +	struct iommu_domain_array_ser *curr_domain_array;
> > > +	struct iommu_device_array_ser *curr_device_array;
> > > +};
> > 
> > IIUIC, there should be one pair of obj + ser in the entire system:
> >  - old kernel has one outgoing obj + ser
> >  - new kernel has one incoming obj + ser
> > right?
> > 
> > If so, things in iommu_flb_obj (except ser) are all transient, and
> > there is no need to preserve them across the two kernels.
> 
> The contents of iommu_flb_obj are not preserved. Only the contents of
> iommu_flb_ser are preserved. Other "curr_" structs in iommu_flb_obj are
> only there for quick access to add new iommus, domains and devices.
> > 
> > It also feels redundant to have this iommu_flb_obj structure. Why
> > not link liveupdate_flb_op_args directly to the ser? Then, things
> > in iommu_flb_obj could be global?
> 
> The liveupdate_flb_op_args is linked directly to the ser, but it only
> contains the physical address for the next kernel. Basically LUO
> provides following mechanism to handle FLBs:
> 
> - data: ser structure for the next kernel.
> - obj: Live object that can be used in the current or next kernel for
>   easy access or staging.
> 
> For example here, iommu_flb_obj has pointers to the end of the array
> linked list of each type.
> 
> Also note LUO keeps separate incoming and outgoing data and obj for each
> FLB. In the new kernel both can exist at the same time, as the incoming
> one stays until finish and preserving for the next live update creates
> the outgoing one. So keeping these in the obj avoids managing two sets
> of globals and their lifetime in the iommu code.

Could incoming and outgoing objects exist in the same time?

Correct me if I am wrong: I expect the lifecycle of an incoming
object will end once liveupdate completes, and the outgoing one
can only exist after that?

Nicolin