Re: [PATCH v4 10/18] iommu/vt-d: Restore IOMMU state and reclaimed domain ids

[Baolu Lu <baolu.lu@linux.intel.com>]

On 8/28/26 02:47, Samiullah Khawaja wrote:
>>> +/**
>>> + * intel_iommu_liveupdate_restore_root_table() - Restore root table 
>>> and reclaim domain IDs
>>> + * @iommu: Target IOMMU
>>> + * @iommu_ser: Serialized IOMMU hardware state from previous kernel
>>> + *
>>> + * Restores the preserved root table and context tables for the 
>>> IOMMU hardware
>>> + * instance across Live Update, and reclaims all domain IDs 
>>> previously allocated
>>> + * to preserved devices so they are not reused.
>>> + */
>>> +void intel_iommu_liveupdate_restore_root_table(struct intel_iommu 
>>> *iommu,
>>> +                           struct iommu_hw_ser *iommu_ser)
>>> +{
>>> +    if (!iommu_ser->intel.restored)
>>> +        iommu_restore_pages(iommu_ser->intel.root_table);
>>> +
>>> +    iommu->root_entry = __va(iommu_ser->intel.root_table);
>>> +
>>> +    if (!iommu_ser->intel.restored)
>>> +        restore_iommu_context(iommu);
>>> +
>>> +    iommu_ser->intel.restored = 1;
>>
>> This uses iommu_ser->intel.restored to prevent restoring the root and
>> context tables multiple times. For this to work safely, iommu_ser-
>>> intel.restored must be 0 the first time restore runs after kexec.
>>
>> The problem is: this field is inside struct iommu_hw_ser, and that
>> struct is allocated in the old kernel. How to ensure that the previous
>> kernel has zeroed this out? Maybe I’m overthinking this.
> 
> This is a valid point. However, the old kernel allocates this struct
> with GFP_ZERO and it never touches the restored field prior to kexec.
> So it should be zero in the new kernel.

That should be fine.

I just found it a bit odd that a variable used only by the incoming
kernel depends on initialization done in the old kernel. :-)

Thanks,
baolu