CONFIG_HAVE_KVM is currently used by some architectures to either
enabled the KVM config proper, or to enable host-side code that is
not part of the KVM module. However, the "select" statement in
virt/kvm/Kconfig corresponds to a third meaning, namely to
enable common Kconfigs required by all architectures that support
KVM.
These three meanings can be replaced respectively by an
architecture-specific Kconfig, by IS_ENABLED(CONFIG_KVM), or by
a new Kconfig symbol that is in turn selected by the
architecture-specific "config KVM".
Start by introducing such a new Kconfig symbol, CONFIG_KVM_COMMON.
Unlike CONFIG_HAVE_KVM, it is selected by CONFIG_KVM, not by
architecture code.
Fixes: 8132d887a702 ("KVM: remove CONFIG_HAVE_KVM_EVENTFD", 2023-12-08)
Cc: Andrew Jones <ajones@ventanamicro.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/arm64/kvm/Kconfig | 1 +
arch/loongarch/kvm/Kconfig | 1 +
arch/mips/kvm/Kconfig | 1 +
arch/powerpc/kvm/Kconfig | 1 +
arch/riscv/kvm/Kconfig | 1 +
arch/s390/kvm/Kconfig | 1 +
arch/x86/kvm/Kconfig | 1 +
virt/kvm/Kconfig | 3 +++
8 files changed, 10 insertions(+)
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index b07c60c9737d..ad5ce0454f17 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -21,6 +21,7 @@ if VIRTUALIZATION
menuconfig KVM
bool "Kernel-based Virtual Machine (KVM) support"
depends on HAVE_KVM
+ select KVM_COMMON
select KVM_GENERIC_HARDWARE_ENABLING
select KVM_GENERIC_MMU_NOTIFIER
select PREEMPT_NOTIFIERS
diff --git a/arch/loongarch/kvm/Kconfig b/arch/loongarch/kvm/Kconfig
index daba4cd5e87d..3b284b7e63ad 100644
--- a/arch/loongarch/kvm/Kconfig
+++ b/arch/loongarch/kvm/Kconfig
@@ -23,6 +23,7 @@ config KVM
depends on HAVE_KVM
select HAVE_KVM_DIRTY_RING_ACQ_REL
select HAVE_KVM_VCPU_ASYNC_IOCTL
+ select KVM_COMMON
select KVM_GENERIC_DIRTYLOG_READ_PROTECT
select KVM_GENERIC_HARDWARE_ENABLING
select KVM_GENERIC_MMU_NOTIFIER
diff --git a/arch/mips/kvm/Kconfig b/arch/mips/kvm/Kconfig
index 428141b0b48f..2eb119e78b6e 100644
--- a/arch/mips/kvm/Kconfig
+++ b/arch/mips/kvm/Kconfig
@@ -21,6 +21,7 @@ config KVM
depends on MIPS_FP_SUPPORT
select EXPORT_UASM
select PREEMPT_NOTIFIERS
+ select KVM_COMMON
select KVM_GENERIC_DIRTYLOG_READ_PROTECT
select HAVE_KVM_VCPU_ASYNC_IOCTL
select KVM_MMIO
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index b47196085a42..5da535e20b6a 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -20,6 +20,7 @@ if VIRTUALIZATION
config KVM
bool
select PREEMPT_NOTIFIERS
+ select KVM_COMMON
select HAVE_KVM_VCPU_ASYNC_IOCTL
select KVM_VFIO
select IRQ_BYPASS_MANAGER
diff --git a/arch/riscv/kvm/Kconfig b/arch/riscv/kvm/Kconfig
index 1fd76aee3b71..55f81377d260 100644
--- a/arch/riscv/kvm/Kconfig
+++ b/arch/riscv/kvm/Kconfig
@@ -24,6 +24,7 @@ config KVM
select HAVE_KVM_IRQ_ROUTING
select HAVE_KVM_MSI
select HAVE_KVM_VCPU_ASYNC_IOCTL
+ select KVM_COMMON
select KVM_GENERIC_DIRTYLOG_READ_PROTECT
select KVM_GENERIC_HARDWARE_ENABLING
select KVM_MMIO
diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig
index bb6d90351119..f89bedbe63bd 100644
--- a/arch/s390/kvm/Kconfig
+++ b/arch/s390/kvm/Kconfig
@@ -25,6 +25,7 @@ config KVM
select HAVE_KVM_VCPU_ASYNC_IOCTL
select KVM_ASYNC_PF
select KVM_ASYNC_PF_SYNC
+ select KVM_COMMON
select HAVE_KVM_IRQCHIP
select HAVE_KVM_IRQ_ROUTING
select HAVE_KVM_INVALID_WAKEUPS
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index b07247b0b958..c8e62a371d24 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -24,6 +24,7 @@ config KVM
depends on HIGH_RES_TIMERS
depends on X86_LOCAL_APIC
select PREEMPT_NOTIFIERS
+ select KVM_COMMON
select KVM_GENERIC_MMU_NOTIFIER
select HAVE_KVM_IRQCHIP
select HAVE_KVM_PFNCACHE
diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
index 6793211a0b64..cce5c03ecc92 100644
--- a/virt/kvm/Kconfig
+++ b/virt/kvm/Kconfig
@@ -3,6 +3,9 @@
config HAVE_KVM
bool
+
+config KVM_COMMON
+ bool
select EVENTFD
config HAVE_KVM_PFNCACHE
--
2.39.1On Thu, Jan 04, 2024, Paolo Bonzini wrote: > CONFIG_HAVE_KVM is currently used by some architectures to either > enabled the KVM config proper, or to enable host-side code that is > not part of the KVM module. However, the "select" statement in > virt/kvm/Kconfig corresponds to a third meaning, namely to > enable common Kconfigs required by all architectures that support > KVM. > > These three meanings can be replaced respectively by an > architecture-specific Kconfig, by IS_ENABLED(CONFIG_KVM), or by > a new Kconfig symbol that is in turn selected by the > architecture-specific "config KVM". > > Start by introducing such a new Kconfig symbol, CONFIG_KVM_COMMON. > Unlike CONFIG_HAVE_KVM, it is selected by CONFIG_KVM, not by > architecture code. Why? I don't get it, just have code that cares do IS_ENABLED(CONFIG_KVM). Except for the MIPS usage of HAVE_KVM that you solved by adding CPU_SUPPORTS_VZ, I got all the way there using just CONFIG_KVM[*]. Ah, and so does this series for the most part, the only usage of CONFIG_KVM_COMMON is in scripts/gdb/linux/constants.py.in. Honestly, adding a Kconfig just so that VMX's posted interrupts that arrive in the host can be printed when KVM is built as a module is a waste of a Kconfig. [*] https://lore.kernel.org/all/20230916003118.2540661-12-seanjc@google.com
On Fri, Jan 5, 2024 at 8:13 PM Sean Christopherson <seanjc@google.com> wrote: > > Start by introducing such a new Kconfig symbol, CONFIG_KVM_COMMON. > > Unlike CONFIG_HAVE_KVM, it is selected by CONFIG_KVM, not by > > architecture code. > > Why? I don't get it, just have code that cares do IS_ENABLED(CONFIG_KVM). Except > for the MIPS usage of HAVE_KVM that you solved by adding CPU_SUPPORTS_VZ, I got > all the way there using just CONFIG_KVM[*]. > > Ah, and so does this series for the most part, the only usage of CONFIG_KVM_COMMON > is in scripts/gdb/linux/constants.py.in. Honestly, adding a Kconfig just so that > VMX's posted interrupts that arrive in the host can be printed when KVM is built > as a module is a waste of a Kconfig. There is one extra thing that CONFIG_KVM_COMMON does, which is to avoid having to select common requirements in all architectures. I jotted this to solve the reported randconfig failure, which is why CONFIG_KVM_COMMON only requires "select EVENTFD", but looking more closely it should also select PREEMPT_NOTIFIERS and INTERVAL_TREE. Both are used by virt/kvm/kvm_main.c, and loongarch + riscv both lack INTERVAL_TREE so I do think it's a good idea to introduce this symbol (though it requires a v2). > [*] https://lore.kernel.org/all/20230916003118.2540661-12-seanjc@google.com I guess you mean https://lore.kernel.org/all/20230916003118.2540661-8-seanjc@google.com/. Paolo
On Fri, Jan 05, 2024, Paolo Bonzini wrote: > On Fri, Jan 5, 2024 at 8:13 PM Sean Christopherson <seanjc@google.com> wrote: > > > Start by introducing such a new Kconfig symbol, CONFIG_KVM_COMMON. > > > Unlike CONFIG_HAVE_KVM, it is selected by CONFIG_KVM, not by > > > architecture code. > > > > Why? I don't get it, just have code that cares do IS_ENABLED(CONFIG_KVM). Except > > for the MIPS usage of HAVE_KVM that you solved by adding CPU_SUPPORTS_VZ, I got > > all the way there using just CONFIG_KVM[*]. > > > > Ah, and so does this series for the most part, the only usage of CONFIG_KVM_COMMON > > is in scripts/gdb/linux/constants.py.in. Honestly, adding a Kconfig just so that > > VMX's posted interrupts that arrive in the host can be printed when KVM is built > > as a module is a waste of a Kconfig. > > There is one extra thing that CONFIG_KVM_COMMON does, which is to > avoid having to select common requirements in all architectures. Oooh, gotcha. FWIW, I would love to unify the "menuconfig VIRTUALIZATION" and "config KVM" entries, but I can't think of a sane way to do that without ending up with something like KVM_COMMON. :-/ > I jotted this to solve the reported randconfig failure, which is why > CONFIG_KVM_COMMON only requires "select EVENTFD", but looking more > closely it should also select PREEMPT_NOTIFIERS and INTERVAL_TREE. > Both are used by virt/kvm/kvm_main.c, and loongarch + riscv both lack > INTERVAL_TREE so I do think it's a good idea to introduce this symbol > (though it requires a v2). > > > [*] https://lore.kernel.org/all/20230916003118.2540661-12-seanjc@google.com > > I guess you mean > https://lore.kernel.org/all/20230916003118.2540661-8-seanjc@google.com/. Doh, yes.
On Thu, Jan 04, 2024 at 03:59:56PM -0500, Paolo Bonzini wrote:
> CONFIG_HAVE_KVM is currently used by some architectures to either
> enabled the KVM config proper, or to enable host-side code that is
> not part of the KVM module. However, the "select" statement in
> virt/kvm/Kconfig corresponds to a third meaning, namely to
> enable common Kconfigs required by all architectures that support
> KVM.
>
> These three meanings can be replaced respectively by an
> architecture-specific Kconfig, by IS_ENABLED(CONFIG_KVM), or by
> a new Kconfig symbol that is in turn selected by the
> architecture-specific "config KVM".
>
> Start by introducing such a new Kconfig symbol, CONFIG_KVM_COMMON.
> Unlike CONFIG_HAVE_KVM, it is selected by CONFIG_KVM, not by
> architecture code.
>
> Fixes: 8132d887a702 ("KVM: remove CONFIG_HAVE_KVM_EVENTFD", 2023-12-08)
> Cc: Andrew Jones <ajones@ventanamicro.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> arch/arm64/kvm/Kconfig | 1 +
> arch/loongarch/kvm/Kconfig | 1 +
> arch/mips/kvm/Kconfig | 1 +
> arch/powerpc/kvm/Kconfig | 1 +
> arch/riscv/kvm/Kconfig | 1 +
> arch/s390/kvm/Kconfig | 1 +
> arch/x86/kvm/Kconfig | 1 +
> virt/kvm/Kconfig | 3 +++
> 8 files changed, 10 insertions(+)
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
© 2016 - 2025 Red Hat, Inc.