From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Like Xu <like.xu@linux.intel.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>, Len Brown <lenb@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86: Add Intel CPUID.1F cpuid emulation support
Date: Wed, 24 Apr 2019 07:32:38 -0700 [thread overview]
Message-ID: <20190424143238.GB18442@linux.intel.com> (raw)
In-Reply-To: <1555915234-2536-1-git-send-email-like.xu@linux.intel.com>
Now that I understand how min() works...
On Mon, Apr 22, 2019 at 02:40:34PM +0800, Like Xu wrote:
> Expose Intel V2 Extended Topology Enumeration Leaf to guest only when
> host system has multiple software-visible die within each package.
>
> Signed-off-by: Like Xu <like.xu@linux.intel.com>
> ---
> arch/x86/kvm/cpuid.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index fd39516..9fc14f2 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -65,6 +65,16 @@ u64 kvm_supported_xcr0(void)
> return xcr0;
> }
>
> +/* We need to check if the host cpu has multi-chip packaging technology. */
> +static bool kvm_supported_intel_mcp(void)
> +{
> + u32 eax, ignored;
> +
> + cpuid_count(0x1f, 0, &eax, &ignored, &ignored, &ignored);
This is broken because of how CPUID works for unsupported input leafs:
If a value entered for CPUID.EAX is higher than the maximum input value
for basic or extended function for that processor then the data for the
highest basic information leaf is returned.
For example, my system with a max basic leaf of 0x16 returns 0x00000e74
for CPUID.1F.EAX.
> +
> + return boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && (eax != 0);
Checking 'eax != 0' is broken as it will be '0' when SMT is disabled. ecx
is the obvious choice since bits 15:8 are guaranteed to be non-zero when
the leaf is valid.
I think we can skip the vendor check. AFAIK, CPUID.1F isn't used by AMD,
and since AMD and Intel try to maintain a semblance of CPUID compatibility
it seems more likely that AMD/Hygon would implement CPUID.1F as-is rather
than repurpose it to mean something else entirely.
> +}
> +
> #define F(x) bit(X86_FEATURE_##x)
>
> int kvm_update_cpuid(struct kvm_vcpu *vcpu)
> @@ -426,6 +436,7 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
> switch (function) {
> case 0:
> entry->eax = min(entry->eax, (u32)(f_intel_pt ? 0x14 : 0xd));
> + entry->eax = kvm_supported_intel_mcp() ? 0x1f : entry->eax;
If we put everything together, I think the code can be reduced to:
/* comment about multi-chip leaf... */
if (entry->eax >= 0x1f && cpuid_ecx(0x1f))
entry->eax = 0x1f;
else
entry->eax = min(entry->eax,
(u32)(f_intel_pt ? 0x14 : 0xd));
> break;
> case 1:
> entry->edx &= kvm_cpuid_1_edx_x86_features;
> @@ -544,6 +555,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
> entry->edx = edx.full;
> break;
> }
> + /* function 0x1f has additional index. */
> + case 0x1f:
> /* function 0xb has additional index. */
> case 0xb: {
> int i, level_type;
> --
> 1.8.3.1
>
next prev parent reply other threads:[~2019-04-24 14:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-22 6:40 [PATCH] KVM: x86: Add Intel CPUID.1F cpuid emulation support Like Xu
2019-04-22 15:53 ` Konrad Rzeszutek Wilk
2019-04-22 16:56 ` Sean Christopherson
2019-04-22 18:35 ` Sean Christopherson
2019-04-23 3:23 ` Like Xu
2019-04-23 17:44 ` Sean Christopherson
2019-04-24 1:59 ` Like Xu
2019-04-24 13:53 ` Sean Christopherson
2019-04-24 14:32 ` Sean Christopherson [this message]
2019-04-25 2:58 ` Like Xu
2019-04-25 4:18 ` Xiaoyao Li
2019-04-25 6:02 ` Like Xu
2019-04-25 6:30 ` Xiaoyao Li
2019-04-25 7:07 ` Like Xu
2019-04-25 14:19 ` Sean Christopherson
2019-04-25 15:33 ` Like Xu
2019-04-25 16:28 ` Xiaoyao Li
2019-04-26 1:30 ` Like Xu
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=20190424143238.GB18442@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=kvm@vger.kernel.org \
--cc=lenb@kernel.org \
--cc=like.xu@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=tglx@linutronix.de \
/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