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 04:15:56PM +0000, Samiullah Khawaja wrote:
>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.

Having implemented this now, I am thinking about this again with respect
to the scope of this series. To limit the scope of this series I am
going to refuse preservation of devices that have ATS enabled. Once the
base preservation logic goes in, I can add a separate series on top of
it to add that support.

The ATS adoption would need new helpers in the PCI core, handling of the
ATS state in the context entries, and the disable-to-enable,
enable-to-disable and STU mismatch for a live device. That is worth its
own review rather than part of an already large series.

This essentially means that preservation is supported if pci=noats is
used, since by default ATS is enabled if the device supports it.

Thanks,
Sami