On Mon, Feb 07 2022, Matthew Rosato <mjrosato@xxxxxxxxxxxxx> wrote: > On 2/7/22 3:35 AM, Cornelia Huck wrote: >> On Fri, Feb 04 2022, Matthew Rosato <mjrosato@xxxxxxxxxxxxx> 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. Yes. Remind me again: if you do standard vfio-pci without the extensions grabbing some card-specific information and making them available to the guest, you get a working setup, it just always looks like a specific card, right? > > 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? Complex :) I'm not really sure whether it's worth the hassle on an odd chance that we may want it for a !KVM usecase in the future (that goes beyond the "base" vfio-pci support.) OTOH, it would be cleaner. I'm a bit torn on this one.
