Message ID | 20221022082643.1725875-1-pbonzini@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4242:0:0:0:0:0 with SMTP id s2csp1157467wrr; Sat, 22 Oct 2022 04:17:30 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6P4I+kj+xpAwwX4/cbwqLAiiAcIb5cdX0d6n6smS0WeduVKmCTegtiSfG9eOzFj4snphcu X-Received: by 2002:a17:906:ee86:b0:741:89bc:27a1 with SMTP id wt6-20020a170906ee8600b0074189bc27a1mr19804274ejb.725.1666437450138; Sat, 22 Oct 2022 04:17:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666437450; cv=none; d=google.com; s=arc-20160816; b=E2HfdlUmbcy/cVUlvNsdSjchIkHfnehXwGcHCPQfl0Uh3rxQdlhcGp+RK4xq71EdP3 2x/RzSfP7V+JjzZzq6T0Cd656VWZY7UxG0UkRoqx1Uv7gt/HQt6x0JIQrQ5LMYGhee7e rasiXfBde71tSh0QPUviuobhmFvtiZCXino4rta/1mqedtkV6vInUZe54fQTfgofNtr+ YPrXV1p6prPo/a/vz2b9cvkCJwzjTV2TcQ0hiDzyvtwHpnLkhPrD5eTSouNwht0+rcXs ElKfsn9kKf6lQ0c2FyM1mza3V7y+1JSkrG6/GZXMOTgTjL7KSp38kj7XGw0S4FzabAgQ I1TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Z4xH2gIaFjaMtuLR3rjMmby3hquw36E2ehtRGHxZNnk=; b=afK+0vyKbsSJrwEkoqien/dQr8VZg2QpFnvKgXzfHXU5kX+qNEkk7ZldWYIY/ayE2u iY0kZpMK5hZnaskM0FK1gZmuGkiiUIsh1p45BuPFAnR0oQMsxyzXsScL8R8Z7lkk1uFb YtkYtXOR56WEK7sTdA/iKJgkPSIzw6NZUcWxYaUo+1t1n82ZJlAsvzK6ZvEIhA8L39J3 WvcRKnIAffm4JhWH/JnTJDKyOk2NgaTUwNc/UZzl6XDS2sFIXnO+UA+KdS83oWEGlp6p R0GFZoSbrAglHwk4c9S/bOqumPJ/GNDmbRK92ymImIHr4wSHIRY5rQUsiwxQE9MsbgV8 ifhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fpATHsU6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hr18-20020a1709073f9200b0073d626e2ef8si20794752ejc.461.2022.10.22.04.17.05; Sat, 22 Oct 2022 04:17:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=fpATHsU6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231206AbiJVLQx (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Sat, 22 Oct 2022 07:16:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50420 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231183AbiJVLQh (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 22 Oct 2022 07:16:37 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC3FD2DAC0F for <linux-kernel@vger.kernel.org>; Sat, 22 Oct 2022 03:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666435269; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=Z4xH2gIaFjaMtuLR3rjMmby3hquw36E2ehtRGHxZNnk=; b=fpATHsU6P9PGi/sCXxIoEkGWsy0kvActYAjx1QvbIMH4CvX7rhpJth8XRXnqxyIPgT/PSC JrJc84yd1dTT6sCHHhK2vOIyrPVZ0QjMdSOlG8RDlzRX2eswFPBIGTNjSg0L1nmF4AM51L tJj78egF4tC7W1WaAtfybnJw2TC9IYc= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-656-2XO7Ra7wNaWtadjImSpXMA-1; Sat, 22 Oct 2022 04:26:54 -0400 X-MC-Unique: 2XO7Ra7wNaWtadjImSpXMA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2E60D804186; Sat, 22 Oct 2022 08:26:54 +0000 (UTC) Received: from virtlab701.virt.lab.eng.bos.redhat.com (virtlab701.virt.lab.eng.bos.redhat.com [10.19.152.228]) by smtp.corp.redhat.com (Postfix) with ESMTP id 78D932166B2C; Sat, 22 Oct 2022 08:26:45 +0000 (UTC) From: Paolo Bonzini <pbonzini@redhat.com> To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, jmattson@google.com Subject: [PATCH] KVM: x86: Do not expose the host value of CPUID.8000001EH Date: Sat, 22 Oct 2022 04:26:43 -0400 Message-Id: <20221022082643.1725875-1-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747386315608594722?= X-GMAIL-MSGID: =?utf-8?q?1747386315608594722?= |
Series |
KVM: x86: Do not expose the host value of CPUID.8000001EH
|
|
Commit Message
Paolo Bonzini
Oct. 22, 2022, 8:26 a.m. UTC
Several fields of CPUID.8000001EH (ExtendedApicId in EAX[31:0],
CoreId in EBX[7:0], NodeId in ECX[7:0]) vary on each processor,
and it is simply impossible to fit the right values in the
KVM_GET_SUPPORTED_CPUID API, in such a way that they can be
passed to KVM_SET_CPUID2.
The most likely way to avoid confusion in the guest is to zero
out all the values. Userspace will most likely override it
anyway if it want to present a specific topology to the guest.
This patch essentially reverts commit 382409b4c43e ("kvm: x86: Include
CPUID leaf 0x8000001e in kvm's supported CPUID").
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
arch/x86/kvm/cpuid.c | 3 +++
1 file changed, 3 insertions(+)
Comments
On 10/22/2022 4:26 PM, Paolo Bonzini wrote: > Several fields of CPUID.8000001EH (ExtendedApicId in EAX[31:0], > CoreId in EBX[7:0], NodeId in ECX[7:0]) vary on each processor, > and it is simply impossible to fit the right values in the > KVM_GET_SUPPORTED_CPUID API, in such a way that they can be > passed to KVM_SET_CPUID2. > > The most likely way to avoid confusion in the guest is to zero > out all the values. Userspace will most likely override it > anyway if it want to present a specific topology to the guest. > > This patch essentially reverts commit 382409b4c43e ("kvm: x86: Include > CPUID leaf 0x8000001e in kvm's supported CPUID"). Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > arch/x86/kvm/cpuid.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index a0292ba650df..380b71600a9e 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -1193,6 +1193,9 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function) > entry->ebx = entry->ecx = entry->edx = 0; > break; > case 0x8000001e: > + /* Different on each processor, just hide it. */ > + entry->eax = entry->ebx = entry->ecx = 0; > + entry->edx = 0; > break; > case 0x8000001F: > if (!kvm_cpu_cap_has(X86_FEATURE_SEV)) {
On Sat, Oct 22, 2022, Paolo Bonzini wrote: > Several fields of CPUID.8000001EH (ExtendedApicId in EAX[31:0], > CoreId in EBX[7:0], NodeId in ECX[7:0]) vary on each processor, > and it is simply impossible to fit the right values in the > KVM_GET_SUPPORTED_CPUID API, in such a way that they can be > passed to KVM_SET_CPUID2. The same is true for 0xb and 0x1f, why delete 0x8000001e but keep those? I agree that KVM_GET_SUPPORTED_CPUID can't get this right, but KVM can at least be consistent with itself. > The most likely way to avoid confusion in the guest is to zero > out all the values. Userspace will most likely override it > anyway if it want to present a specific topology to the guest. > > This patch essentially reverts commit 382409b4c43e ("kvm: x86: Include > CPUID leaf 0x8000001e in kvm's supported CPUID"). Why not do a full revert? > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > arch/x86/kvm/cpuid.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index a0292ba650df..380b71600a9e 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -1193,6 +1193,9 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function) > entry->ebx = entry->ecx = entry->edx = 0; > break; > case 0x8000001e: > + /* Different on each processor, just hide it. */ > + entry->eax = entry->ebx = entry->ecx = 0; > + entry->edx = 0; Putting EDX in a separate line is rather weird.
On 10/25/22 18:46, Sean Christopherson wrote: > On Sat, Oct 22, 2022, Paolo Bonzini wrote: >> Several fields of CPUID.8000001EH (ExtendedApicId in EAX[31:0], >> CoreId in EBX[7:0], NodeId in ECX[7:0]) vary on each processor, >> and it is simply impossible to fit the right values in the >> KVM_GET_SUPPORTED_CPUID API, in such a way that they can be >> passed to KVM_SET_CPUID2. > > The same is true for 0xb and 0x1f, why delete 0x8000001e but keep those? I agree > that KVM_GET_SUPPORTED_CPUID can't get this right, but KVM can at least be > consistent with itself. 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. It would indeed be more consistent with 0xb and 0x1f if KVM set EAX to the X2APIC id automatically; on the other hand the value of EAX for 0x8000001eh would not be consistent with EBX and ECX, which I think is worse. >> The most likely way to avoid confusion in the guest is to zero >> out all the values. Userspace will most likely override it >> anyway if it want to present a specific topology to the guest. >> >> This patch essentially reverts commit 382409b4c43e ("kvm: x86: Include >> CPUID leaf 0x8000001e in kvm's supported CPUID"). > > Why not do a full revert? To document the reason why the leaf is hidden; after all it was gotten wrong once. >> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> >> --- >> arch/x86/kvm/cpuid.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c >> index a0292ba650df..380b71600a9e 100644 >> --- a/arch/x86/kvm/cpuid.c >> +++ b/arch/x86/kvm/cpuid.c >> @@ -1193,6 +1193,9 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function) >> entry->ebx = entry->ecx = entry->edx = 0; >> break; >> case 0x8000001e: >> + /* Different on each processor, just hide it. */ >> + entry->eax = entry->ebx = entry->ecx = 0; >> + entry->edx = 0; > > Putting EDX in a separate line is rather weird. It is, but entry->edx is not different on each processor (it is not defined at all, and so it should be zeroed). Paolo
On Tue, Oct 25, 2022, Paolo Bonzini wrote: > On 10/25/22 18:46, Sean Christopherson wrote: > > On Sat, Oct 22, 2022, Paolo Bonzini wrote: > > > Several fields of CPUID.8000001EH (ExtendedApicId in EAX[31:0], > > > CoreId in EBX[7:0], NodeId in ECX[7:0]) vary on each processor, > > > and it is simply impossible to fit the right values in the > > > KVM_GET_SUPPORTED_CPUID API, in such a way that they can be > > > passed to KVM_SET_CPUID2. > > > > The same is true for 0xb and 0x1f, why delete 0x8000001e but keep those? I agree > > that KVM_GET_SUPPORTED_CPUID can't get this right, but KVM can at least be > > consistent with itself. > > 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. 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.
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
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index a0292ba650df..380b71600a9e 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -1193,6 +1193,9 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function) entry->ebx = entry->ecx = entry->edx = 0; break; case 0x8000001e: + /* Different on each processor, just hide it. */ + entry->eax = entry->ebx = entry->ecx = 0; + entry->edx = 0; break; case 0x8000001F: if (!kvm_cpu_cap_has(X86_FEATURE_SEV)) {