On 9/26/25 4:54 AM, Duan, Zhenzhong wrote:
>
>> -----Original Message-----
>> From: Nicolin Chen <[email protected]>
>> Subject: Re: [PATCH v6 05/22] hw/pci: Introduce
>> pci_device_get_viommu_flags()
>>
>> On Wed, Sep 24, 2025 at 07:05:42AM +0000, Duan, Zhenzhong wrote:
>>>> From: Nicolin Chen <[email protected]>
>>>> 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" :)
> Yes, that needs to introduce another callback to forward the caps early,
> unnecessarily complex.
>
>> 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:
>> "
> OK, will drop 3 and add the side note.
With Nicolin's suggestions:
Reviewed-by: Eric Auger <[email protected]>
Eric
>
> Thanks
> Zhenzhong
>
