[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aPuaTnIdexx8erS5@infradead.org>
Date: Fri, 24 Oct 2025 08:25:02 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Ramshankar Venkataraman <ramshankar.venkataraman@...cle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] KVM: Re-export kvm_enable_virtualization() and
kvm_disable_virtualization() as normal (global) exports rather than only to
KVM's vendor modules
On Fri, Oct 24, 2025 at 06:08:38PM +0530, Ramshankar Venkataraman wrote:
> Starting with 6.12.0 (3efc57369a0ce8f76bf0804f7e673982384e4ac9) KVM modules
> enabled virtualization in hardware during module init rather than when the
> first VM is started. This meant that VirtualBox users had to manually
> unload/disable KVM modules in-order to use VirtualBox.
>
> Starting with 6.16.0, kvm_enable_virtualization() and
> kvm_disable_virtualization() functions were exported. VirtualBox made use
> of these functions so our users did not need to unload/disable KVM kernel
> modules in-order to use VirtualBox. This made it possible to run KVM and
> VirtualBox side by side.
So? We never export modules for out of tree drivers. This should be
a reminder to the virtualbox project that they really should have
switched to using the kvm kernel code 10 years ago instead of wasting
time on their own buggy version. They managed to get that memo on
other platforms the hard way, and maybe this is the final wink for
Linux for folks to understand.
Powered by blists - more mailing lists