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

[Samiullah Khawaja <skhawaja@google.com>]

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@google.com>
>>
>> > +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