On Wed, Sep 24, 2025 at 07:05:42AM +0000, Duan, Zhenzhong wrote: > >From: Nicolin Chen <nicol...@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
