>-----Original Message-----
>From: Nicolin Chen <nicol...@nvidia.com>
>Subject: Re: [PATCH 1/5] vfio/iommufd: Save host iommu capabilities in
>VFIODevice.caps
>
>On Wed, Apr 16, 2025 at 05:49:09AM +0000, Duan, Zhenzhong wrote:
>> >-----Original Message-----
>> >From: Nicolin Chen <nicol...@nvidia.com>
>
>> > And I was expecting the
>> >vIOMMU could provide some callback for the core to use so it'll
>> >return a valid caps pointer.
>>
>> Any reason for that?
>> iommufd_backend_get_device_info() need iommufd fd and devid which are
>> all provided by VFIO, why not let VFIO call it directly and let vIOMMU query
>> cap through .get_cap().
>
>I thought we had an agreement on letting the core code stay away
>from vendor types and handlers, which seems to be a common sense?
>At least the kernel side never handles "VTD" and "SMMU" types, so
>shouldn't we do the same in QEMU?
As Cedric suggested in [1] "The IOMMU backend implementation could be anything,
legacy, iommufd, iommufd v2, some other framework and the vIOMMU shouldn't be
aware of its implementation.", so now we have core code handle the vendor data
and provide a general capability query through .get_cap() callback.
>
>IMHO, it's okay to do the ioctl in the core code since it has all
>the inputs as you said. Yet, the core code should only decode the
>IOMMU_HW_CAP_PCI_PASID_ caps out of the out_capabilities, as they
>were filled by the core code in the kernel. For the type/data, it
>can store them in a cap structure, and forward to the vendor code
>via a callback function to decode them there for some common bits
>(e.g. nesting).
This is exactly what I had ever done in an old version, VFIO provides
hiodc->get_host_iommu_info() callback for vIOMMU to get host IOMMU info.
See https://lists.gnu.org/archive/html/qemu-devel/2024-04/msg00770.html
and https://lists.gnu.org/archive/html/qemu-devel/2024-04/msg00784.html
Cedric suggested a more general interface between VFIO and vIOMMU:
"we could introduce in the vIOMMU <-> HostIOMMUDevice
interface capabilities, or features, to check more precisely the level
of compatibility between the vIOMMU and the host IOMMU device. This is
similar to what is done between QEMU and KVM"
See [1] for discussion details.
[1] https://lists.gnu.org/archive/html/qemu-devel/2024-04/msg02658.html
Thanks
Zhenzhong
>
>The other way around is to do the ioctl in the vendor code via a
>callback function that returns the cap structure. I think this is
>slightly better, since the vendor code knows the exact data size
>and it can validate the returned "type" immediately.
>
>Thanks
>Nicolin
