Re: [PATCH v1 15/22] Add iommufd configure option

["Cédric Le Goater" <clg@redhat.com>]

On 9/20/23 05:42, Duan, Zhenzhong wrote:
> 
> 
>> -----Original Message-----
>> From: Cédric Le Goater <clg@redhat.com>
>> Sent: Wednesday, September 20, 2023 1:08 AM
>> Subject: Re: [PATCH v1 15/22] Add iommufd configure option
>>
>> On 8/30/23 12:37, Zhenzhong Duan wrote:
>>> This adds "--enable-iommufd/--disable-iommufd" to enable or disable
>>> iommufd support, enabled by default.
>>
>> Why would someone want to disable support at compile time ? It might
> 
> For those users who only want to support legacy container feature?
> Let me know if you still prefer to drop this patch, I'm fine with that.

I think it is too early.

>> have been useful for dev but now QEMU should self-adjust at runtime
>> depending only on the host capabilities AFAIUI. Am I missing something ?
> 
> IOMMUFD doesn't support all features of legacy container, so QEMU
> doesn't self-adjust at runtime by checking if host supports IOMMUFD.
> We need to specify it explicitly to use IOMMUFD as below:
> 
>      -object iommufd,id=iommufd0
>      -device vfio-pci,host=0000:02:00.0,iommufd=iommufd0

OK. I am not sure this is the correct interface yet. At first glance,
I wouldn't introduce a new object for a simple backend depending on a
kernel interface. I would tend to prefer a "iommu-something" property
of the vfio-pci device with string values: "legacy", "iommufd", "default"
and define the various interfaces (the ops you proposed) for each
depending on the user preference and the capabilities of the host and
possibly the device.

I might be wrong and this might have been discussed before. If so, it
should go in the cover letter with other things : what is this patchset
providing to VFIO (multiple iommu backends), how it is reaching that
goal, how is it organized, how do we deal with the special case (spapr),
what's the user interface, etc.


   
Thanks,

C.


> Thanks
> Zhenzhong
>