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

[Baolu Lu]

On 8/28/26 01:52, Samiullah Khawaja wrote:
> > > +    ret = domain_reattach_iommu(dmar_domain, iommu, device_ser);
> > > +    if (ret)
> > > +        return ret;
> > > +
> > > +    info->domain = dmar_domain;
> > > +    info->domain_attached = true;
> > > +    spin_lock_irqsave(&dmar_domain->lock, flags);
> > > +    list_add(&info->link, &dmar_domain->devices);
> > > +    spin_unlock_irqrestore(&dmar_domain->lock, flags);
> > > +
> > > +    if (!sm_supported(iommu))
> > > +        intel_iommu_enable_pci_ats(info);
> >
> > Could you please clarify the PCI ATS behavior across live update?
> >
> > My understanding is that PCI devices may bypass reset during kexec and
> > are then re-initialized by the new kernel (is that correct?). If so, ATS
> > state in hardware would depend on its state before kexec in the old
> > kernel.
> >
> > In a normal reboot, ATS is expected to be disabled and the device ATC is
> > empty. But that assumption may not hold for live update. If that is
> > true, can we still use the same approach to keep hardware ATS state and
> > info->ats_enabled in sync?
>
> Regarding ATS, it remains enabled in the preserved device during kexec
> and we should keep it in sync with the info->ats_enabled here. We might
> have to disable it in the next kernel if it is unsupported (or disabled
> globally) in the next kernel. I will put those changes here in next
> revision.

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.

By the way, is disabling ATS an option? The current design already
requires disabling PCI/PRI during kexec, right? If so, nothing
functionally depends on ATS at that point. Maybe we should apply the
same policy to ATS as well (i.e., disable ATS and PRI at the same time)?

Thanks,
baolu