> On Aug 18, 2021, at 2:47 PM, Alex Williamson <alex.william...@redhat.com>
> wrote:
>
> On Mon, 16 Aug 2021 09:42:37 -0700
> Elena Ufimtseva <elena.ufimts...@oracle.com> wrote:
>
>> diff --git a/hw/vfio/meson.build b/hw/vfio/meson.build
>> index da9af297a0..739b30be73 100644
>> --- a/hw/vfio/meson.build
>> +++ b/hw/vfio/meson.build
>> @@ -8,6 +8,7 @@ vfio_ss.add(when: 'CONFIG_VFIO_PCI', if_true: files(
>> 'display.c',
>> 'pci-quirks.c',
>> 'pci.c',
>> + 'user.c',
>> ))
>> vfio_ss.add(when: 'CONFIG_VFIO_CCW', if_true: files('ccw.c'))
>> vfio_ss.add(when: 'CONFIG_VFIO_PLATFORM', if_true: files('platform.c'))
>
> Wouldn't it make sense to be able to configure QEMU with any
> combination of vfio-pci and/or vfio-user-pci support rather than
> statically tying vfio-user-pci to vfio-pci? Not to mention that doing
> so would help to more formally define the interface operations between
> kernel and user options, for example fewer tests of vbasedev->proxy and
> perhaps more abstraction through ops structures. Thanks,
>
We can certainly add another config option for vfio-user.
As far as an ops vector vs vbasedev->proxy tests, it’s a
matter personal preference. I prefer the changes inline when they
are this small, but we can make a vector if that’s what you want.
JJ
