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

[Pranjal Shrivastava]

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.

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