Re: [PATCH 06/26] KVM: Drop CONFIG_KVM_VFIO and just look at KVM+VFIO
On Fri, 15 Sep 2023 17:30:58 -0700 Sean Christopherson wrote: > Drop KVM's KVM_VFIO Kconfig, and instead compile in VFIO support if > and only if VFIO itself is enabled. Similar to the recent change to have > VFIO stop looking at HAVE_KVM, compiling in support for talking to VFIO > just because the architecture supports VFIO is nonsensical. > > This fixes a bug where RISC-V doesn't select KVM_VFIO, i.e. would silently > fail to do connect KVM and VFIO, even though RISC-V supports VFIO. The > bug is benign as the only driver in all of Linux that actually uses the > KVM reference provided by VFIO is KVM-GT, which is x86/Intel specific. > > Signed-off-by: Sean Christopherson > --- > arch/arm64/kvm/Kconfig | 1 - > arch/powerpc/kvm/Kconfig | 1 - > arch/s390/kvm/Kconfig| 1 - > arch/x86/kvm/Kconfig | 1 - > virt/kvm/Kconfig | 3 --- > virt/kvm/Makefile.kvm| 4 +++- > virt/kvm/vfio.h | 2 +- > 7 files changed, 4 insertions(+), 9 deletions(-) Reviewed-by: Alex Williamson > diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig > index 83c1e09be42e..2b5c332f157d 100644 > --- a/arch/arm64/kvm/Kconfig > +++ b/arch/arm64/kvm/Kconfig > @@ -28,7 +28,6 @@ menuconfig KVM > select KVM_MMIO > select KVM_GENERIC_DIRTYLOG_READ_PROTECT > select KVM_XFER_TO_GUEST_WORK > - select KVM_VFIO > select HAVE_KVM_EVENTFD > select HAVE_KVM_IRQFD > select HAVE_KVM_DIRTY_RING_ACQ_REL > diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig > index 902611954200..c4beb49c0eb2 100644 > --- a/arch/powerpc/kvm/Kconfig > +++ b/arch/powerpc/kvm/Kconfig > @@ -22,7 +22,6 @@ config KVM > select PREEMPT_NOTIFIERS > select HAVE_KVM_EVENTFD > select HAVE_KVM_VCPU_ASYNC_IOCTL > - select KVM_VFIO > select IRQ_BYPASS_MANAGER > select HAVE_KVM_IRQ_BYPASS > select INTERVAL_TREE > diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig > index 45fdf2a9b2e3..459d536116a6 100644 > --- a/arch/s390/kvm/Kconfig > +++ b/arch/s390/kvm/Kconfig > @@ -31,7 +31,6 @@ config KVM > select HAVE_KVM_IRQ_ROUTING > select HAVE_KVM_INVALID_WAKEUPS > select HAVE_KVM_NO_POLL > - select KVM_VFIO > select INTERVAL_TREE > select MMU_NOTIFIER > help > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig > index ed90f148140d..0f01e5600b5f 100644 > --- a/arch/x86/kvm/Kconfig > +++ b/arch/x86/kvm/Kconfig > @@ -45,7 +45,6 @@ config KVM > select HAVE_KVM_NO_POLL > select KVM_XFER_TO_GUEST_WORK > select KVM_GENERIC_DIRTYLOG_READ_PROTECT > - select KVM_VFIO > select INTERVAL_TREE > select HAVE_KVM_PM_NOTIFIER if PM > select KVM_GENERIC_HARDWARE_ENABLING > diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig > index 484d0873061c..f0be3b55cea6 100644 > --- a/virt/kvm/Kconfig > +++ b/virt/kvm/Kconfig > @@ -59,9 +59,6 @@ config HAVE_KVM_MSI > config HAVE_KVM_CPU_RELAX_INTERCEPT > bool > > -config KVM_VFIO > - bool > - > config HAVE_KVM_INVALID_WAKEUPS > bool > > diff --git a/virt/kvm/Makefile.kvm b/virt/kvm/Makefile.kvm > index 2c27d5d0c367..29373b59d89a 100644 > --- a/virt/kvm/Makefile.kvm > +++ b/virt/kvm/Makefile.kvm > @@ -6,7 +6,9 @@ > KVM ?= ../../../virt/kvm > > kvm-y := $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/binary_stats.o > -kvm-$(CONFIG_KVM_VFIO) += $(KVM)/vfio.o > +ifdef CONFIG_VFIO > +kvm-y += $(KVM)/vfio.o > +endif > kvm-$(CONFIG_KVM_MMIO) += $(KVM)/coalesced_mmio.o > kvm-$(CONFIG_KVM_ASYNC_PF) += $(KVM)/async_pf.o > kvm-$(CONFIG_HAVE_KVM_IRQ_ROUTING) += $(KVM)/irqchip.o > diff --git a/virt/kvm/vfio.h b/virt/kvm/vfio.h > index e130a4a03530..af475a323965 100644 > --- a/virt/kvm/vfio.h > +++ b/virt/kvm/vfio.h > @@ -2,7 +2,7 @@ > #ifndef __KVM_VFIO_H > #define __KVM_VFIO_H > > -#ifdef CONFIG_KVM_VFIO > +#if IS_ENABLED(CONFIG_KVM) && IS_ENABLED(CONFIG_VFIO) > int kvm_vfio_ops_init(void); > void kvm_vfio_ops_exit(void); > #else
Re: [PATCH 06/26] KVM: Drop CONFIG_KVM_VFIO and just look at KVM+VFIO
On Mon, Sep 18, 2023 at 08:52:40AM -0700, Sean Christopherson wrote: > > I wonder if we should be making the VFIO drivers that need the kvm to > > ask for it? 'select CONFIG_NEED_VFIO_KVM' or something? > > I wondered the same thing, if only to make it easier to track which > drivers actually end up interacting directly with KVM. There are two usages I've seen.. GVT's uage is just totally broken: https://lore.kernel.org/kvm/661447fd-b041-c08d-cedc-341b31c40...@intel.com/ It is trying to use KVM to write protect IOVA DMA memory, and it just doesn't work. If we want to do something like this the core vfio code should provide this service and it should be wired into KVM properly. power and s390 have actual architectural "virtual machines" and they need actual arch operations to install VFIO devices into those things. In this regard having the arch opt into the integration would make some sense. I expect this will get worse in our CC future where VFIO devices will need to be passed into arch specific CC code somehow. This arch stuff isn't cleanly done, the code is sprinkled all over the place. Some in mdevs, some in PCI arch code, some in #ifdefs.. Maybe the CC people will clean it up instead of making the mess bigger :) Jason
Re: [PATCH 06/26] KVM: Drop CONFIG_KVM_VFIO and just look at KVM+VFIO
On Mon, Sep 18, 2023, Jason Gunthorpe wrote:
> On Fri, Sep 15, 2023 at 05:30:58PM -0700, Sean Christopherson wrote:
> > Drop KVM's KVM_VFIO Kconfig, and instead compile in VFIO support if
> > and only if VFIO itself is enabled. Similar to the recent change to have
> > VFIO stop looking at HAVE_KVM, compiling in support for talking to VFIO
> > just because the architecture supports VFIO is nonsensical.
> >
> > This fixes a bug where RISC-V doesn't select KVM_VFIO, i.e. would silently
> > fail to do connect KVM and VFIO, even though RISC-V supports VFIO. The
> > bug is benign as the only driver in all of Linux that actually uses the
> > KVM reference provided by VFIO is KVM-GT, which is x86/Intel specific.
>
> Hmm, I recall that all the S390 drivers need it as well.
>
> static int vfio_ap_mdev_open_device(struct vfio_device *vdev)
> {
> struct ap_matrix_mdev *matrix_mdev =
> container_of(vdev, struct ap_matrix_mdev, vdev);
>
> if (!vdev->kvm)
> return -EINVAL;
>
> return vfio_ap_mdev_set_kvm(matrix_mdev, vdev->kvm);
Ah, I missed that the KVM reference was routed through VFIO in that case.
> I wonder if we should be making the VFIO drivers that need the kvm to
> ask for it? 'select CONFIG_NEED_VFIO_KVM' or something?
I wondered the same thing, if only to make it easier to track which drivers
actually
end up interacting directly with KVM.
> Regardless, I fully agree with getting rid of the arch flag.
>
> Reviewed-by: Jason Gunthorpe
>
> > --- a/virt/kvm/Makefile.kvm
> > +++ b/virt/kvm/Makefile.kvm
> > @@ -6,7 +6,9 @@
> > KVM ?= ../../../virt/kvm
> >
> > kvm-y := $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/binary_stats.o
> > -kvm-$(CONFIG_KVM_VFIO) += $(KVM)/vfio.o
> > +ifdef CONFIG_VFIO
> > +kvm-y += $(KVM)/vfio.o
> > +endif
>
> I wonder if kvm-m magically works in kbuild so you don't need the ifdef?
Yeah, that should work, no idea why I added the ifdef.
Re: [PATCH 06/26] KVM: Drop CONFIG_KVM_VFIO and just look at KVM+VFIO
On Fri, Sep 15, 2023 at 05:30:58PM -0700, Sean Christopherson wrote:
> Drop KVM's KVM_VFIO Kconfig, and instead compile in VFIO support if
> and only if VFIO itself is enabled. Similar to the recent change to have
> VFIO stop looking at HAVE_KVM, compiling in support for talking to VFIO
> just because the architecture supports VFIO is nonsensical.
>
> This fixes a bug where RISC-V doesn't select KVM_VFIO, i.e. would silently
> fail to do connect KVM and VFIO, even though RISC-V supports VFIO. The
> bug is benign as the only driver in all of Linux that actually uses the
> KVM reference provided by VFIO is KVM-GT, which is x86/Intel specific.
Hmm, I recall that all the S390 drivers need it as well.
static int vfio_ap_mdev_open_device(struct vfio_device *vdev)
{
struct ap_matrix_mdev *matrix_mdev =
container_of(vdev, struct ap_matrix_mdev, vdev);
if (!vdev->kvm)
return -EINVAL;
return vfio_ap_mdev_set_kvm(matrix_mdev, vdev->kvm);
I wonder if we should be making the VFIO drivers that need the kvm to
ask for it? 'select CONFIG_NEED_VFIO_KVM' or something?
Regardless, I fully agree with getting rid of the arch flag.
Reviewed-by: Jason Gunthorpe
> --- a/virt/kvm/Makefile.kvm
> +++ b/virt/kvm/Makefile.kvm
> @@ -6,7 +6,9 @@
> KVM ?= ../../../virt/kvm
>
> kvm-y := $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/binary_stats.o
> -kvm-$(CONFIG_KVM_VFIO) += $(KVM)/vfio.o
> +ifdef CONFIG_VFIO
> +kvm-y += $(KVM)/vfio.o
> +endif
I wonder if kvm-m magically works in kbuild so you don't need the ifdef?
Jason
[PATCH 06/26] KVM: Drop CONFIG_KVM_VFIO and just look at KVM+VFIO
Drop KVM's KVM_VFIO Kconfig, and instead compile in VFIO support if and only if VFIO itself is enabled. Similar to the recent change to have VFIO stop looking at HAVE_KVM, compiling in support for talking to VFIO just because the architecture supports VFIO is nonsensical. This fixes a bug where RISC-V doesn't select KVM_VFIO, i.e. would silently fail to do connect KVM and VFIO, even though RISC-V supports VFIO. The bug is benign as the only driver in all of Linux that actually uses the KVM reference provided by VFIO is KVM-GT, which is x86/Intel specific. Signed-off-by: Sean Christopherson --- arch/arm64/kvm/Kconfig | 1 - arch/powerpc/kvm/Kconfig | 1 - arch/s390/kvm/Kconfig| 1 - arch/x86/kvm/Kconfig | 1 - virt/kvm/Kconfig | 3 --- virt/kvm/Makefile.kvm| 4 +++- virt/kvm/vfio.h | 2 +- 7 files changed, 4 insertions(+), 9 deletions(-) diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index 83c1e09be42e..2b5c332f157d 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -28,7 +28,6 @@ menuconfig KVM select KVM_MMIO select KVM_GENERIC_DIRTYLOG_READ_PROTECT select KVM_XFER_TO_GUEST_WORK - select KVM_VFIO select HAVE_KVM_EVENTFD select HAVE_KVM_IRQFD select HAVE_KVM_DIRTY_RING_ACQ_REL diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index 902611954200..c4beb49c0eb2 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -22,7 +22,6 @@ config KVM select PREEMPT_NOTIFIERS select HAVE_KVM_EVENTFD select HAVE_KVM_VCPU_ASYNC_IOCTL - select KVM_VFIO select IRQ_BYPASS_MANAGER select HAVE_KVM_IRQ_BYPASS select INTERVAL_TREE diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig index 45fdf2a9b2e3..459d536116a6 100644 --- a/arch/s390/kvm/Kconfig +++ b/arch/s390/kvm/Kconfig @@ -31,7 +31,6 @@ config KVM select HAVE_KVM_IRQ_ROUTING select HAVE_KVM_INVALID_WAKEUPS select HAVE_KVM_NO_POLL - select KVM_VFIO select INTERVAL_TREE select MMU_NOTIFIER help diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index ed90f148140d..0f01e5600b5f 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -45,7 +45,6 @@ config KVM select HAVE_KVM_NO_POLL select KVM_XFER_TO_GUEST_WORK select KVM_GENERIC_DIRTYLOG_READ_PROTECT - select KVM_VFIO select INTERVAL_TREE select HAVE_KVM_PM_NOTIFIER if PM select KVM_GENERIC_HARDWARE_ENABLING diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig index 484d0873061c..f0be3b55cea6 100644 --- a/virt/kvm/Kconfig +++ b/virt/kvm/Kconfig @@ -59,9 +59,6 @@ config HAVE_KVM_MSI config HAVE_KVM_CPU_RELAX_INTERCEPT bool -config KVM_VFIO - bool - config HAVE_KVM_INVALID_WAKEUPS bool diff --git a/virt/kvm/Makefile.kvm b/virt/kvm/Makefile.kvm index 2c27d5d0c367..29373b59d89a 100644 --- a/virt/kvm/Makefile.kvm +++ b/virt/kvm/Makefile.kvm @@ -6,7 +6,9 @@ KVM ?= ../../../virt/kvm kvm-y := $(KVM)/kvm_main.o $(KVM)/eventfd.o $(KVM)/binary_stats.o -kvm-$(CONFIG_KVM_VFIO) += $(KVM)/vfio.o +ifdef CONFIG_VFIO +kvm-y += $(KVM)/vfio.o +endif kvm-$(CONFIG_KVM_MMIO) += $(KVM)/coalesced_mmio.o kvm-$(CONFIG_KVM_ASYNC_PF) += $(KVM)/async_pf.o kvm-$(CONFIG_HAVE_KVM_IRQ_ROUTING) += $(KVM)/irqchip.o diff --git a/virt/kvm/vfio.h b/virt/kvm/vfio.h index e130a4a03530..af475a323965 100644 --- a/virt/kvm/vfio.h +++ b/virt/kvm/vfio.h @@ -2,7 +2,7 @@ #ifndef __KVM_VFIO_H #define __KVM_VFIO_H -#ifdef CONFIG_KVM_VFIO +#if IS_ENABLED(CONFIG_KVM) && IS_ENABLED(CONFIG_VFIO) int kvm_vfio_ops_init(void); void kvm_vfio_ops_exit(void); #else -- 2.42.0.459.ge4e396fd5e-goog
