From: Sean Christopherson <seanjc@google.com>
To: Kai Huang <kai.huang@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Chao Gao <chao.gao@intel.com>
Subject: Re: [PATCH v2 3/6] KVM: Add a module param to allow enabling virtualization when KVM is loaded
Date: Wed, 29 May 2024 16:07:58 -0700 [thread overview]
Message-ID: <Zle1TrfeJDeXLtLk@google.com> (raw)
In-Reply-To: <291ecb3e791606c3437fc415343eb4a25e531cc3.camel@intel.com>
On Wed, May 29, 2024, Kai Huang wrote:
> On Wed, 2024-05-29 at 08:01 -0700, Sean Christopherson wrote:
> > Enabling virtualization should be entirely transparent to userspace,
> > at least from a functional perspective; if changing how KVM enables virtualization
> > breaks userspace then we likely have bigger problems.
>
> I am not sure how should I interpret this?
>
> "having a module param" doesn't necessarily mean "entirely transparent to
> userspace", right? :-)
Ah, sorry, that was unclear. By "transparent to userspace" I meant the
functionality of userspace VMMs wouldn't be affected if we add (or delete) a
module param. E.g. QEMU should work exactly the same regardless of when KVM
enables virtualization.
> > Performance is secondary for me, the primary motivation is simplifying the overall
> > KVM code base. Yes, we _could_ use on_each_cpu() and enable virtualization
> > on-demand for TDX, but as above, it's extra complexity without any meaningful
> > benefit, at least AFAICT.
>
> Either way works for me.
>
> I just think using a module param to resolve some problem while there can
> be solution completely in the kernel seems overkill :-)
The module param doesn't solve the problem, e.g. we could solve this entirely
in-kernel simply by having KVM unconditionally enable virtualization during
initialization. The module param is mostly there to continue playing nice with
out-of-tree hypervisors, and to a lesser extent to give us a "break in case of
fire" knob.
next prev parent reply other threads:[~2024-05-29 23:08 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 2:28 [PATCH v2 0/6] KVM: Register cpuhp/syscore callbacks when enabling virt Sean Christopherson
2024-05-22 2:28 ` [PATCH v2 1/6] KVM: Register cpuhp and syscore callbacks when enabling hardware Sean Christopherson
2024-05-22 6:10 ` Chao Gao
2024-05-29 14:29 ` Sean Christopherson
2024-05-22 2:28 ` [PATCH v2 2/6] KVM: Rename functions related to enabling virtualization hardware Sean Christopherson
2024-05-22 7:10 ` Chao Gao
2024-05-22 22:34 ` Huang, Kai
2024-05-22 2:28 ` [PATCH v2 3/6] KVM: Add a module param to allow enabling virtualization when KVM is loaded Sean Christopherson
2024-05-22 22:27 ` Huang, Kai
2024-05-23 4:23 ` Chao Gao
2024-05-23 23:11 ` Huang, Kai
2024-05-24 2:39 ` Chao Gao
2024-05-27 22:36 ` Huang, Kai
2024-05-29 15:01 ` Sean Christopherson
2024-05-29 22:45 ` Huang, Kai
2024-05-29 23:07 ` Sean Christopherson [this message]
2024-05-30 0:06 ` Huang, Kai
2024-05-22 2:28 ` [PATCH v2 4/6] KVM: Add arch hooks for enabling/disabling virtualization Sean Christopherson
2024-05-22 22:33 ` Huang, Kai
2024-05-28 22:50 ` Sean Christopherson
2024-05-23 5:31 ` Chao Gao
2024-05-22 2:28 ` [PATCH v2 5/6] x86/reboot: Unconditionally define cpu_emergency_virt_cb typedef Sean Christopherson
2024-05-22 22:35 ` Huang, Kai
2024-05-23 5:41 ` Chao Gao
2024-05-22 2:28 ` [PATCH v2 6/6] KVM: x86: Register "emergency disable" callbacks when virt is enabled Sean Christopherson
2024-05-22 22:37 ` Huang, Kai
2024-05-23 5:59 ` Chao Gao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zle1TrfeJDeXLtLk@google.com \
--to=seanjc@google.com \
--cc=chao.gao@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.