>-----Original Message-----
>From: Nicolin Chen <nicol...@nvidia.com>
...
>> >I think you did some substantial work to isolate the get_hw_info
>> >part inside the iommufd backend code, which looks nice and clean
>> >as the vIOMMU code simply does iodc->get_cap().
>> >
>> >However, that then makes these direct raw backend function calls
>> >very awkward :-/
>> >
>> >In my view, the way to make sense is either:
>> >* We don't do any isolation, but just call raw backend functions
>> > in vIOMMU code
>> >* We do every isolation, and never call raw backend functions in
>> > vIOMMU code
>>
>> Iommufd backend functions are general for all modules usage including
>> vIOMMU. I think we are not blocking vIOMMU calling raw backend functions.
>
>Well, I am not against doing that. Calling the raw iommufd APIs is
>easier :)
>
>> We just provide a general interface for querying capabilities, not all
>> capabilities
>> are from iommufd get_hw_info result, e.g., aw_bits.
>
>Question is why we need a general interface for get_hw_info(), yet
>not for other iommufd APIs.
Because other iommufd APIs are already abstract and hides vendor difference,
but get_hw_info() is not, it returns raw vendor data.
This makes consumer of this raw vendor data have to recognize the vendor data
format.
For example, when virtio-iommu wants to know host iommu capability, it has to
check
raw data from get_hw_info(), we hide this difference in the backend so
virtio-iommu
could just call .get_cap(HOST_IOMMU_DEVICE_CAP_*), no matter what underlying
platform is, Vtd, smmuv3, etc..
>
>IIRC, Cedirc's suggested a general interface for get_hw_info so the
>vIOMMU code can be unaware of the underlying source (doesn't matter
>if it's from iommufd or from vfio).
>
>I see aw_bits from QEMU command line. Mind elaborating?
You mean aw_bits for virtual intel-iommu, that defines the IOVA address width
of intel-iommu.
We need to check aw_bits from host intel-iommu with virtual intel-iommu's to
determine
compatibility.
Thanks
Zhenzhong
