From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <seanjc@google.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, jmattson@google.com
Subject: Re: [PATCH] KVM: x86: Do not expose the host value of CPUID.8000001EH
Date: Tue, 25 Oct 2022 23:31:26 +0200 [thread overview]
Message-ID: <c71894e8-d6ee-9a2d-3054-5d4df61fe122@redhat.com> (raw)
In-Reply-To: <Y1hUZYs7kz7JXmr7@google.com>
On 10/25/22 23:25, Sean Christopherson wrote:
>> 0xb and 0x1f are already special cased because EDX is set to the X2APIC id.
>> KVM knows how to do that unlike the NodeId and CoreId.
> But KVM doesn't properly support 0xB/0x1F. E.g. if usersepace regurgitates
> KVM_GET_SUPPORTED_CPUID back into KVM_SET_CPUID2, all vCPUs will observe the same
> x2APIC ID in EDX, and it will be a host x2APIC ID to boot.
>
> KVM only handles the where userspace provides 0xB.1 (or 0x1F.1), the guest performs
> CPUID with ECX>1,_and_ userspace doesn't provide the exact CPUID entry.
Ah, you're right - I confused it with the "undefined leaves" behavior here:
} else {
*eax = *ebx = *ecx = *edx = 0;
/*
* When leaf 0BH or 1FH is defined, CL is pass-through
* and EDX is always the x2APIC ID, even for undefined
* subleaves. Index 1 will exist iff the leaf is
* implemented, so we pass through CL iff leaf 1
* exists. EDX can be copied from any existing index.
*/
if (function == 0xb || function == 0x1f) {
entry = kvm_find_cpuid_entry(vcpu, function, 1);
if (entry) {
*ecx = index & 0xff;
*edx = entry->edx;
}
}
}
but KVM in principle could set EDX to the right value for 0xB and 0x1F,
the x2APIC ID is available for the kernel LAPIC case. 0x8000001e cannot
be fixed up the same way.
> I suppose one could argue that KVM needs to communicate to userspace that KVM
> emulates the edge case behavior of CPUID 0xB and 0x1F, but I would argue that KVM
> communicates that by announcing a max basic leaf >= 0xB/0x1F.
I agree (or we could fix it up automagically if so inclined). Either
way it should be documented at the end of api.rst.
Paolo
prev parent reply other threads:[~2022-10-25 21:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-22 8:26 Paolo Bonzini
2022-10-24 13:06 ` Xiaoyao Li
2022-10-25 16:46 ` Sean Christopherson
2022-10-25 21:09 ` Paolo Bonzini
2022-10-25 21:25 ` Sean Christopherson
2022-10-25 21:31 ` Paolo Bonzini [this message]
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=c71894e8-d6ee-9a2d-3054-5d4df61fe122@redhat.com \
--to=pbonzini@redhat.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=seanjc@google.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
all inboxes | Powered by JetHome®