Re: [PATCH v2 02/16] iommu: Implement IOMMU Live update FLB callbacks

[Samiullah Khawaja]

On Mon, May 18, 2026 at 12:33:25PM +0000, Pranjal Shrivastava wrote:
> On Fri, May 01, 2026 at 09:45:19PM +0000, David Matlack wrote:
> > On 2026-04-27 05:56 PM, Samiullah Khawaja wrote:
> > > Add liveupdate FLB for IOMMU state preservation. Use KHO preserve memory
> > > alloc/free helper functions to allocate memory for the IOMMU Live update
> > > FLB object and the serialization structs for device, domain and iommu.
> > >
> > > During retrieve, walk through the preserved obj array headers and
> > > restore each folio. Also recreate the FLB obj.
> > >
> > > Signed-off-by: Samiullah Khawaja <skhawaja@xxxxxxxxxx>
> >
> > > +static void *iommu_liveupdate_restore_array(u64 array_phys)
> > > +{
> > > +	struct iommu_array_hdr_ser *array_hdr;
> > > +	void *vaddr = array_phys ? phys_to_virt(array_phys) : NULL;
> > > +
> > > +	while (array_phys) {
> > > +		/*
> > > +		 * Failure to restore preserved IOMMU state is considered fatal.
> > > +		 *
> > > +		 * This is because the IOMMU translations for preserved IOMMUs
> > > +		 * were kept enabled in the previous kernel and the preserved
> > > +		 * devices have their IOMMU domains still present. Not being
> > > +		 * able to restore means that the memory mapped into preserved
> > > +		 * domains might be already corrupted by the preserved devices.
> > > +		 *
> > > +		 * There is no way to confirm the integrity of the memory that
> > > +		 * was mapped. BUG_ON is the safest option at this point.
> > > +		 */
> > > +		BUG_ON(!kho_restore_folio(array_phys));
> > > +		array_hdr = phys_to_virt(array_phys);
> > > +		array_phys = array_hdr->next_array_phys;
> > > +	}
> > > +
> > > +	return vaddr;
> > > +}
> >
> > > +static int iommu_liveupdate_flb_retrieve(struct liveupdate_flb_op_args *argp)
> > > +{
> > > +	struct iommu_flb_obj *obj;
> > > +	struct iommu_flb_ser *ser;
> > > +
> > > +	obj = kzalloc_obj(*obj, GFP_KERNEL);
> > > +	if (!obj)
> > > +		return -ENOMEM;
> >
> > Should this be considered fatal for the same reason
> > iommu_liveupdate_restore_array() is considered fatal? If anything in
> > iommu_liveupdate_flb_retrieve() fails then the risk of corruption as
> > described in iommu_liveupdate_restore_array() is possible.
>
> Righ... Nice catch. I suppose we should BUG_ON() this because
> luo_flb_file_finish_one [1] returns void. Thus, if we return -ENOMEM
> here all we get is a WARN_ON without panic.

The error is propagated by get_flb_incoming(). The finish path has a
WARN. But that is fine because finish won't be called as can_finish()
will fail if FLB retrieve fails and restore cannot be done.

I will add a comment about this here.
> We can't statically allocate obj in liveupdate_flb_op_args because obj
> is a void ptr. I believe we must add a BUG_ON() here.
>
> > > +
> > > +	/* Data must be present and valid from the previous kernel */
> > > +	BUG_ON(!kho_restore_folio(argp->data));
> > > +
> > > +	mutex_init(&obj->lock);
> > > +	ser = phys_to_virt(argp->data);
> > > +	obj->ser = ser;
> > > +
> > > +	obj->curr_domain_array = iommu_liveupdate_restore_array(ser->iommu_domain_array_phys);
> > > +	obj->curr_device_array = iommu_liveupdate_restore_array(ser->device_array_phys);
> > > +	obj->curr_iommu_array = iommu_liveupdate_restore_array(ser->iommu_array_phys);
> > > +	argp->obj = obj;
> > > +	return 0;
> > > +}
>
> Thanks,
> Praan
>
> [1] https://elixir.bootlin.com/linux/v7.1-rc3/source/kernel/liveupdate/luo_flb.c#L208