Linus reported a build regression when CONFIG_KVM={y,m} but
CONFIG_KVM_INTEL and CONFIG_KVM_AMD are both n. If that happens, kvm.ko
tries to call cpu_emergency_register_virt_callback() but that function
does not exist due to a mismatch between KVM code and the common x86
files arch/x86/include/asm/reboot.h and arch/x86/kernel/reboot.c.
kvm.ko is nothing but library code shared by kvm-intel.ko and kvm-amd.ko.
It provides no functionality on its own and it is unnecessary unless one
of the vendor-specific module is compiled. In particular, /dev/kvm is
not created until one of kvm-intel.ko or kvm-amd.ko is loaded.
It is still useful to have CONFIG_KVM, as it lets the user make kvm.ko
built-in; but it is pointless to build it unless the user picked at least
one vendor module.
Skipping the build of kvm.ko is already enough to fix the build regression.
However, the second patch also adjust the reboot.[ch] files to test the
Kconfig symbol that corresponds to arch/x86/kvm/x86.c, which is now
CONFIG_KVM_X86_COMMON.
More cleanups are possible in arch/x86 in the other direction, making code
depend on the specific vendor-specific module that needs it. For example,
current_save_fsgs only has to be exported if IS_MODULE(CONFIG_KVM_INTEL).
This is left for later.
Paolo
Paolo Bonzini (2):
KVM: x86: leave kvm.ko out of the build if no vendor module is
requested
x86/reboot: emergency callbacks are now registered by common KVM code
arch/x86/include/asm/reboot.h | 4 ++--
arch/x86/kernel/reboot.c | 4 ++--
arch/x86/kvm/Kconfig | 7 +++++--
arch/x86/kvm/Makefile | 2 +-
4 files changed, 10 insertions(+), 7 deletions(-)
--
2.43.5
