Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2736321yba; Mon, 22 Apr 2019 12:01:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqx83OwVpKo4MQEJB//qoKR7nZeb1jGV7TnN0PefDNZPefwd4hUfVw6XcaB+bQy+GQECoaQ+ X-Received: by 2002:a63:c34c:: with SMTP id e12mr20544172pgd.279.1555959689372; Mon, 22 Apr 2019 12:01:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555959689; cv=none; d=google.com; s=arc-20160816; b=LkDYamYymO67lkfLeAvRk0hTSOLLy2HGJ7XmU8Gf1wtPW84VHeELBCf6ZW2V3AC8RR st54rQSVRs1DVMR3S+NrPfOojIWYSZkv5gvo5EMwy1Phshu0RH5jKGaIxVL9cEiSSv55 6qrzTtWyDzuchf7qFj9V42oPqMRGdRKWcwErsw7x7nVsbEA7mplEceO2QjTe8HB4MqvO JF2rQqypT974PYuEtxR438l/z6tSZPBOObuoIRwrN/SAg9IAuhXmTTtZGFTFUjk+XzM/ 2SfVYEY9FI2n5xqOFsT1JLfft9lYwVVhDQbApQIlIvEfaNenao1qZdMAO08ZewhEdVpo pxwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=PEDvZMUoJj7SHwRKLuMVQCotiOjPCpJYj/j8oUXgVFM=; b=IX7v3sMMmdAU0xAAzzTRx9kRHfk/Ia21EQzn9xmc0xuVnNznNyeeh67CrvIVn4AC85 Zk4rk75rM3xybEs3wRfc4U9xeH0+F/2VgRb7ivoPqWZiZBFC+5z8gX/TCZXrfk/DlXPi Q3vgchvdpIBSkQtBvjQhNdA3M/R//3OHfXK1E4yxlDYujqp+ZuMNnsix9oNOKlH9Y8wE 1/XhwFGVBa8WAGTtJJe4IQjcV2hoRYC2Ypqb2jQlvopfeFXxvlkWNw242Z45/lFdAyr7 n6vUyug97lMB7khbhIGlR4vz0/LSsE3Peu2MSTBhTjL0W1rYKAo4sWC76D9+B1b8zrvT hoXA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g136si14806112pfb.29.2019.04.22.12.01.14; Mon, 22 Apr 2019 12:01:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727852AbfDVSky (ORCPT + 99 others); Mon, 22 Apr 2019 14:40:54 -0400 Received: from mga02.intel.com ([134.134.136.20]:59587 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727014AbfDVSky (ORCPT ); Mon, 22 Apr 2019 14:40:54 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2019 11:40:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,382,1549958400"; d="scan'208";a="339761584" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.181]) by fmsmga005.fm.intel.com with ESMTP; 22 Apr 2019 11:35:53 -0700 Date: Mon, 22 Apr 2019 11:35:53 -0700 From: Sean Christopherson To: Like Xu Cc: kvm@vger.kernel.org, Paolo Bonzini , Thomas Gleixner , Len Brown , linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: x86: Add Intel CPUID.1F cpuid emulation support Message-ID: <20190422183553.GH1236@linux.intel.com> References: <1555915234-2536-1-git-send-email-like.xu@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1555915234-2536-1-git-send-email-like.xu@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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); > + > + return boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && (eax != 0); > +} > + > #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; This all seems unnecessary. And by 'all', I mean the existing Intel PT and XSAVE leaf checks, as well as the new mcp check. entry->eax comes directly from hardware, and unless I missed something, PT and XSAVE are only exposed to the guest when they're supported in hardware. In other words, KVM will never need to adjust entry->eax to expose PT or XSAVE. The original min() check was added by commit 0771671749b5 ("KVM: Enhance guest cpuid management"), which doesn't provide any explicit information on why KVM does min() in the first place. Given that the original code was "entry->eax = min(entry->eax, (u32)0xb);", my *guess* is that the idea was to always report "Extended Topology Enumeration Leaf" as supported so that userspace can enumerate the VM's topology to the guest even when hardware itself doesn't do so. Assuming we want to allow userspace to use "V2 Extended Topology Enumeration Leaf" regardless of hardware support, then this can simply be: entry->eax = min(entry->eax, (u32)0xf); Or am I completely missing something? > 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. */ The original comment is rather useless, it's obvious from the code that it has additional indices. No need to repeat its sins. A more useful comment would be to explain that 0x1f and 0xb have identical formats and thus can be handled by common code. Which begs the question, why does leaf 0x1f exist? AFAICT the only difference is that 0x1f supports additional "level types", but 0x1f's types are backwards compatibile. Any idea why leaf 0xb wasn't simply extended for the new types? > + case 0x1f: > /* function 0xb has additional index. */ > case 0xb: { > int i, level_type; > -- > 1.8.3.1 >