On Wed, May 22, 2024, Kai Huang wrote:
> On 22/05/2024 8:02 am, Sean Christopherson wrote:
> > On Wed, May 15, 2024, Kai Huang wrote:
> > > How about we just make all emergency virtualization disable code
> > > unconditional but not guided by CONFIG_KVM_INTEL || CONFIG_KVM_AMD, i.e.,
> > > revert commit
> > >
> > > 261cd5ed934e ("x86/reboot: Expose VMCS crash hooks if and only if
> > > KVM_{INTEL,AMD} is enabled")
> > >
> > > It makes sense anyway from the perspective that it allows the out-of-tree
> > > kernel module hypervisor to use this mechanism w/o needing to have the
> > > kernel built with KVM enabled in Kconfig. Otherwise, strictly speaking,
> > > IIUC, the kernel won't be able to support out-of-tree module hypervisor as
> > > there's no other way the module can intercept emergency reboot.
> >
> > Practically speaking, no one is running an out-of-tree hypervisor without either
> > (a) KVM being enabled in the .config, or (b) non-trivial changes to the kernel.
>
> Just for curiosity: why b) is required to support out-of-tree hypervisor
> when KVM is disabled in Kconfig? I am probably missing something.
A variety of hooks that are likely needed for any x86 hypervisor (especially on
Intel) are guarded by CONFIG_KVM. E.g. the posted interrupt vectors (though it's
definitely possible to use a different model than KVM), the entry point for
trampolining NMIs (though again, a hypervisor could just do "INT 2", at least
until FRED comes along), and probably a few other things.
I'm sure it's possible to workaround any issues, but I would be quite surprised
if out-of-tree code went through the effort of functioning with a kernel built
to play nice with KVM. Who knows, maybe I'm entirely wrong :-)
