On Fri, Feb 04 2022, Matthew Rosato <[email protected]> wrote:
> This was previously removed as unnecessary; while that was true, subsequent
> changes will make KVM an additional required component for vfio-pci-zdev.
> Let's re-introduce CONFIG_VFIO_PCI_ZDEV as now there is actually a reason
> to say 'n' for it (when not planning to CONFIG_KVM).
Hm... can the file be split into parts that depend on KVM and parts that
don't? Does anybody ever use vfio-pci on a non-kvm s390 system?
[Apologies if that has been discussed before, this is my first look at
this series.]
>
> Signed-off-by: Matthew Rosato <[email protected]>
> ---
> drivers/vfio/pci/Kconfig | 11 +++++++++++
> drivers/vfio/pci/Makefile | 2 +-
> include/linux/vfio_pci_core.h | 2 +-
> 3 files changed, 13 insertions(+), 2 deletions(-)
>
On 2/7/22 3:35 AM, Cornelia Huck wrote:
> On Fri, Feb 04 2022, Matthew Rosato <[email protected]> wrote:
>
>> This was previously removed as unnecessary; while that was true, subsequent
>> changes will make KVM an additional required component for vfio-pci-zdev.
>> Let's re-introduce CONFIG_VFIO_PCI_ZDEV as now there is actually a reason
>> to say 'n' for it (when not planning to CONFIG_KVM).
>
> Hm... can the file be split into parts that depend on KVM and parts that
> don't? Does anybody ever use vfio-pci on a non-kvm s390 system?
>
It is possible to split out most of the prior CLP/ vfio capability work
(but it would not be a totally clean split, zpci_group_cap for example
would need to have an inline ifdef since it references a KVM structure)
-- I suspect we'll see more of that in the future.
I'm not totally sure if there's value in the information being provided
today -- this CLP information was all added specifically with
userspace->guest delivery in mind. And to answer your other question,
I'm not directly aware of non-kvm vfio-pci usage on s390 today; but that
doesn't mean there isn't any or won't be in the future of course. With
this series, you could CONFIG_KVM=n + CONFIG_VFIO_PCI=y|m and you'll get
the standard vfio-pci support but never any vfio-pci-zdev extension.
If we wanted to provide everything we can where KVM isn't strictly
required, then let's look at what a split would look like:
With or without KVM:
zcpi_base_cap
zpci_group_cap (with an inline ifdef for KVM [1])
zpci_util_cap
zpci_pfip_cap
vfio_pci_info_zdev_add_caps
vfio_pci_zdev_open (ifdef, just return when !KVM [1])
vfio_pci_zdev_release (ifdef, just return when !KVM [1])
KVM only:
vfio_pci_zdev_feat_interp
vfio_pci_zdev_feat_aif
vfio_pci_zdev_feat_ioat
vfio_pci_zdev_group_notifier
I suppose such a split has the benefit of flexibility /
future-proofing... should a non-kvm use case arrive in the future for
s390 and we find we need some s390-specific handling, we're still
building vfio-pci-zdev into vfio-pci by default and can just extend that.
[1] In this case I would propose renaming CONFIG_VFIO_PCI_ZDEV as we
would once again always be building some part of vfio-pci-zdev with
vfio-pci on s390 -- maybe something like CONFIG_VFIO_PCI_ZDEV_KVM (wow
that's a mouthful) and then use this setting to check "KVM" in my above
split. Since this setting will imply PCI, VFIO_PCI and KVM, we can then
s/CONFIG_VFIO_PCI_ZDEV/CONFIG_VFIO_PCI_ZDEV_KVM/ for the rest of the
series (to continue covering cases like we build KVM but not pci, or not
vfio-pci)
How does that sound?