Previously (kernel 6.11 and lower) VMs of other virtualization solutions such as VirtualBox could be started with the KVM module enabled. Since 6.12 setting kvm.enable_virt_at_load=0 needs to be set at boot if the KVM module is enabled, if you want to use other virtualization solution beside KVM. The commit that introduced the new behavior is https://github.com/torvalds/linux/commit/b4886fab6fb620b96ad7eeefb9801c42dfa91741. To be clear it is not about the feature itself, but the default. I am also aware that this might be intentional; but given it deviates from previous/expected behavior, it seems like a regression. The fix would be to set the feature to be off by default. This would be trivial, but first I need to know for sure that this is considered a bug.
On Mon, Dec 16, 2024 at 09:15:22AM +0000, bugzilla-daemon@kernel.org wrote: > Previously (kernel 6.11 and lower) VMs of other virtualization solutions such > as VirtualBox could be started with the KVM module enabled. There is no other in-tree user of the hardware virtualization capabilities, so this can't break anything by definition.
(In reply to hch from comment #1) > On Mon, Dec 16, 2024 at 09:15:22AM +0000, bugzilla-daemon@kernel.org wrote: > > Previously (kernel 6.11 and lower) VMs of other virtualization solutions > such > > as VirtualBox could be started with the KVM module enabled. > > There is no other in-tree user of the hardware virtualization > capabilities, so this can't break anything by definition. That sounds like a dead-end argument to me. What is the use case for this new feature actually? What would be the disadvantage to turn this off by default?
From the kernel docs: kvm.enable_virt_at_load=[KVM,ARM64,LOONGARCH,MIPS,RISCV,X86] If enabled, KVM will enable virtualization in hardware when KVM is loaded, and disable virtualization when KVM is unloaded (if KVM is built as a module). If disabled, KVM will dynamically enable and disable virtualization on-demand when creating and destroying VMs, i.e. on the 0=>1 and 1=>0 transitions of the number of VMs. Enabling virtualization at module lode avoids potential latency for creation of the 0=>1 VM, as KVM serializes virtualization enabling across all online CPUs. The "cost" of enabling virtualization when KVM is loaded, is that doing so may interfere with using out-of-tree hypervisors that want to "own" virtualization hardware. In addition to the latency angle, TDX support is effectively going to require VMX to be enabled when KVM is loaded, i.e. trying to do something different will only delay the inevitable. FWIW, Paolo and I do want to get to a state where out-of-tree hypervisors don't need to do weird things, but it'll take some time to get to that state. https://lore.kernel.org/all/ZwQjUSOle6sWARsr@google.com
(In reply to Sean Christopherson from comment #3) > FWIW, Paolo and I do want to get to a state where out-of-tree hypervisors > don't need to do weird things, but it'll take some time to get to that state. > > https://lore.kernel.org/all/ZwQjUSOle6sWARsr@google.com Thanks for the longer explanation (including the link's content). Given that this was discussed already, I am going to close this then.