Re: [PATCH v4 12/18] iommu/vt-d: Handle reattach of the restored domain

[Samiullah Khawaja <skhawaja@google.com>]

On Fri, Aug 28, 2026 at 11:35:46AM -0300, Jason Gunthorpe wrote:
>On Fri, Aug 28, 2026 at 09:55:18AM +0800, Baolu Lu wrote:
>> That looks reasonable to me. I have no concerns about keeping ATS
>> enabled on preserved devices across kexec reboot, as long as the
>> software state is synchronized in the new kernel.
>
>The new kernel should issue an ATC flush when it changes away from the
>inherented domain.

Yes, I will make sure this happens when we do the retrieval side. It
should mostly work well with the existing replace machinery.
>
>> By the way, is disabling ATS an option?
>
>No, many devices require ATS.

Agreed on the ATS requirement. I had Nicolin's patch series for CXL
devices in mind here.
>
>It is not that ATS and PRI are coupled, there are good reasons to do
>ATS to pinned memory too.
>
>PRI is a PITA, I continue to think PRI through the iommu was a
>mistake. Devices that have device-specific PRI handling are fine
>because that all lives in the VM. Devices relying on SMMU PRI
>forwarding must also somehow not loose any PRI events across the kexec
>and must ultimately inject all of them into the VM.
>
>> The current design already requires disabling PCI/PRI during kexec,
>> right?
>
>That is also not OK, but there certainly is a useful universe of VMs
>that might pretend to use PRI but actually only use device specific
>fault delivery.
>
>So ignoring PRI for the moment is possibly OK. Someone using this
>should understand what VM shapes thay are making and if that
>limitation is OK.

Agreed. To avoid the massive complexity of handling PRI events across
the kexec right now, I explicitly evaluated this during v4 development
and marked PRI as unsupported to limit the scope for now.
>
>Jason

Thanks,
Sami