On Thu, Feb 24, 2022 at 05:43:13PM +0100, Jan Beulich wrote:
> On 24.02.2022 17:37, Roger Pau Monne wrote:
> > Introduce a new field to mark devices as broken: having it set
> > prevents the device from being assigned to guests. Use the field in
> > order to mark ATS devices that have failed a flush as broken, thus
> > preventing them to be assigned to any guest.
> > 
> > This allows the device IOMMU context entry to be cleaned up properly,
> > as calling _pci_hide_device will just change the ownership of the
> > device, but the IOMMU context entry of the device would be left as-is.
> > It would also leak a Domain ID, as removing the device from it's
> > previous owner will allow releasing the DID used by the device without
> > having cleaned up the context entry.
> 
> This DID aspect is VT-d specific, isn't it? I'd be inclined to ask to
> make this explicit (which could be done while committing if no other
> need for a v3 arises).

Indeed. AMD doesn't use iommu_dev_iotlb_flush_timeout so the function
is VT-d specific. What about using:

"Introduce a new field to mark devices as broken: having it set
prevents the device from being assigned to guests. Use the field in
order to mark ATS devices that have failed a flush when using VT-d as
broken, thus preventing them to be assigned to any guest.

This allows the device IOMMU context entry to be cleaned up properly,
as calling _pci_hide_device will just change the ownership of the
device, but the IOMMU context entry of the device would be left as-is.
It would also leak a VT-d Domain ID if using one, as removing the
device from it's previous owner will allow releasing the IOMMU DID
used by the device without having cleaned up the context entry."

Thanks, Roger.

Reply via email to