Re: [PATCH v6 05/22] hw/pci: Introduce pci_device_get_viommu_flags()

[Nicolin Chen <nicolinc@nvidia.com>]

On Wed, Sep 24, 2025 at 07:05:42AM +0000, Duan, Zhenzhong wrote:
> >From: Nicolin Chen <nicolinc@nvidia.com>
> >Subject: Re: [PATCH v6 05/22] hw/pci: Introduce
> >> get_viommu_flags() is designed to return 64bit bitmap of purely vIOMMU
> >> flags which are only determined by user's configuration, no host
> >> capabilities involved. Reasons are:
> >>
> >> 1. host may has heterogeneous IOMMUs, each with different capabilities
> >> 2. this is migration friendly, return value is consistent between source
> >>    and target.
> >> 3. host IOMMU capabilities are passed to vIOMMU through
> >set_iommu_device()
> >>    interface which have to be after attach_device(), when
> >get_viommu_flags()
> >>    is called in attach_device(), there is no way for vIOMMU to get host
> >>    IOMMU capabilities yet, so only pure vIOMMU flags can be returned.
> >
> >"no way" sounds too strong..
> >
> >There is an iommufd_backend_get_device_info() call there. So, we
> >could have passed the host IOMMU capabilities to a vIOMMU. Just,
> >we chose not to (assuming for migration reason?).
> 
> What about 'it's hard for vIOMMU to get host IOMMU...'?

vfio-iommufd core code gets all the host IOMMU caps via the vfio
device but chooses to not forward to vIOMMU. So, it's neither "no
way" nor "hard" :)

To be honest, I don't feel this very related to be the reason 3
to justify for the new op/API. 1 and 2 are quite okay?

Having said that, it's probably good to add as a side note:

"
Note that this op will be invoked at the attach_device() stage, at which
point host IOMMU capabilities are not yet forwarded to the vIOMMU through
the set_iommu_device() callback that will be after the attach_device().

See the below sequence:
"

Nicolin