From: Sean Christopherson <seanjc@google.com>
To: Wei W Wang <wei.w.wang@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/4] KVM: x86: Collect host state snapshots into a struct
Date: Thu, 25 Apr 2024 07:24:25 -0700 [thread overview]
Message-ID: <ZipnmfPs0dP3fRUE@google.com> (raw)
In-Reply-To: <DS0PR11MB6373E404A16BD8CC55128FDFDC172@DS0PR11MB6373.namprd11.prod.outlook.com>
On Thu, Apr 25, 2024, Wei W Wang wrote:
> On Wednesday, April 24, 2024 6:15 AM, Sean Christopherson wrote:
> > Add a global "kvm_host" structure to hold various host values, e.g. for EFER,
> > XCR0, raw MAXPHYADDR etc., instead of having a bunch of one-off variables
> > that inevitably need to be exported, or in the case of shadow_phys_bits, are
> > buried in a random location and are awkward to use, leading to duplicate
> > code.
>
> Looks good. How about applying similar improvements to the module
> parameters as well? I've changed the "enable_pmu" parameter as an example below:
Hmm, I don't hate the idea, but I don't think it would work as well in practice.
For kvm_host, all of the fields it contains were being namespace with "host_<asset>",
And the globals that became kvm_caps all had some variant of kvm_ or kvm_has_ as
a prefix.
For module params and other knobs, the thing being controlled is usually unique
to KVM, and often fairly self-descriptive, so we haven't had to namespace them
muc. And we have params across kvm.ko, kvm-amd.ko, and kvm-intel.ko, which
sometimes weird splits in responsibilities, e.g. enable_apicv is defined by common
x86, but the module params themsleves are defined by SVM and VMX, and for SVM it's
an alias of avic.
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 77352a4abd87..a221ba7b546f 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -1013,7 +1013,7 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
> union cpuid10_eax eax;
> union cpuid10_edx edx;
>
> - if (!enable_pmu || !static_cpu_has(X86_FEATURE_ARCH_PERFMON)) {
> + if (!kvm_caps.enable_pmu || !static_cpu_has(X86_FEATURE_ARCH_PERFMON)) {
If we did try to collect module params in a struct, it should be a unique struct,
because they aren't pure capabilities or host values.
> entry->eax = entry->ebx = entry->ecx = entry->edx = 0;
> break;
> }
next prev parent reply other threads:[~2024-04-25 14:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-23 22:15 [PATCH 0/4] KVM: x86: Collect host state snapshots into a struct Sean Christopherson
2024-04-23 22:15 ` [PATCH 1/4] KVM: x86: Add a struct to consolidate host values, e.g. EFER, XCR0, etc Sean Christopherson
2024-04-25 11:29 ` Wang, Wei W
2024-04-25 14:10 ` Sean Christopherson
2024-04-25 14:37 ` Wang, Wei W
2024-04-25 14:47 ` Sean Christopherson
2024-04-23 22:15 ` [PATCH 2/4] KVM: SVM: Use KVM's snapshot of the host's XCR0 for SEV-ES host state Sean Christopherson
2024-04-23 22:15 ` [PATCH 3/4] KVM: x86/mmu: Snapshot shadow_phys_bits when kvm.ko is loaded Sean Christopherson
2024-04-23 22:15 ` [PATCH 4/4] KVM: x86: Move shadow_phys_bits into "kvm_host", as "maxphyaddr" Sean Christopherson
2024-04-25 11:17 ` [PATCH 0/4] KVM: x86: Collect host state snapshots into a struct Wang, Wei W
2024-04-25 14:24 ` Sean Christopherson [this message]
2024-06-04 23:29 ` Sean Christopherson
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=ZipnmfPs0dP3fRUE@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=wei.w.wang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox