>-----Original Message-----
>From: Nicolin Chen <nicol...@nvidia.com>
>Subject: Re: [PATCH 1/5] vfio/iommufd: Save host iommu capabilities in
>VFIODevice.caps
>
>On Mon, Apr 14, 2025 at 09:30:41AM +0000, Duan, Zhenzhong wrote:
>> >-----Original Message-----
>> >From: Cédric Le Goater <c...@redhat.com>
>> >> @@ -77,6 +77,7 @@ typedef struct VFIODevice {
>> >> bool dirty_tracking; /* Protected by BQL */
>> >> bool iommu_dirty_tracking;
>> >> HostIOMMUDevice *hiod;
>> >> + HostIOMMUDeviceIOMMUFDCaps caps;
>> >
>> >IMO, these capabilities belong to HostIOMMUDevice and not VFIODevice.
>
>It's a bit complicated now, as a cap like PASID more belongs to
>the VFIO device than the IOMMU device, and should be read by
>the PCI VFIO code to set the PASID cap field. With this being
>said...
Yes, and ATS and PRQ capabilities.
>
>> This was trying to address suggestions in [1], caps is generated by IOMMUFD
>backend
>> and is only used by hiod_iommufd_get_cap(), hiod_legacy_vfio_get_cap() never
>> check it. By putting it in VFIODevice, I can save vendor caps in a union and
>> raw
>> data format, hiod_iommufd_get_cap() recognizes the raw data format and can
>> check it for a cap support.
>
>It could still get hiod->caps?
No, in this series, I want to move hiod->caps to VFIODevice->caps,
only interface to get a cap is .get_cap() interface.
>
>I think the legacy pathway could have a NULL hiod or NULL caps,
>so both get_cap() functions could work.
If NULL hiod for legacy pathway, then vIOMMU could not call
hiod_legacy_vfio_get_cap() in any way for VFIO device with legacy backend.
> 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().
Thanks
Zhenzhong
