> > > But I am not sure whether we want to do this (having CONFIG_KVM_INTEL around the > > relevant code). In later patches, you mentioned the case of out-of-tree > > hypervisor, for instance, below in the changelog of patch 04: > > > > There's no need to attempt VMXOFF if KVM (or some other out-of-tree� > > hypervisor) isn't loaded/active... > > > > This means we want to do handle VMCLEAR+VMXOFF in case of out-of-tree hypervisor > > too. So, shouldn't the hooks always exist but not only available when KVM_INTEL > > or KVM_AMD is on, so the out-of-tree hypervisor can register their callbacks? > > Ah, I see how I confused things with that statement. My intent was only to call > out that, technically, a non-NULL callback doesn't mean KVM is loaded. I didn't > intend to sign the kernel up for going out of its way to support out-of-tree hypervisors. I interpret this as: Kernel doesn't officially support the out-of-tree hypervisor, but it provides a callback which the out-of-tree hypervisor can utilize to handle emergency virt disable. But such callback is only available when KVM is turned on in the Kconfig. ? > > Does it read better if I add a "that piggybacked the callback" qualifier? > > There's no need to attempt VMXOFF if KVM (or some other out-of-tree hypervisor > that piggybacked the callback) isn't loaded/active, i.e. if the CPU can't > possibly be post-VMXON. I think so? But overall I just think having to consider out-of-tree hypervisor (we are talking about a loadable module, right) only makes thing more confusing. I guess we can either: 1) Don't mention out-of-tree hypervisor at all. This means kernel doesn't officially provide mechanisms to support out-of-tree hyperivisor (a module). If someone wants to do that, then someone takes the risk. 2) The kernel officially provide the callback to handle emergency virt disable for out-of-tree hypervisor (module) to use. But this callback should be available when KVM is off. ?
