Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1527379yba; Thu, 25 Apr 2019 01:01:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqwbbm/mUCUtEnI/6cH27QzFFQI5nO0KNv/UV/cF8/l6ms2nLcIw63xok70kCW6FIUOFms3P X-Received: by 2002:a62:e301:: with SMTP id g1mr7130060pfh.221.1556179316675; Thu, 25 Apr 2019 01:01:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556179316; cv=none; d=google.com; s=arc-20160816; b=Wc1wMZdAd8Ms0O7n7WTGoWgeIfDiHpeIDabAzS2sV8zkro6iSh4Y4oYRf/AiH3UAa+ rUFgzvaGodMS5Iw4q6HGT3Igzz0mHYo5qzA2m+l28gau9y/POb+e3IqkUGxLYodg9Vpo /J6kh3d+hUWyWpZPZJNu3qjETemOThGKJe2IsZ6tWYO+K0qtwovl/2IOJyhDD5JeOdy9 kFMaxcly98x0NFudQg4t0L2Ru5paGh6oYsusObb9TN3E/DmQSzMfNRBMcEN2D2xe4Qzq d+h9pxbiXtPE4I3zkmXO68CdA7meTkqg6BQ5xxa7sHXI5afvHwaYEzbXQ6OofCSIA01D ltMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=tZpgvrKXFHaSFNX5e/E4foQ8TZJEN52xnQip3QUX0Cw=; b=TliPlptmcii0M9GmL2ffDqy90ClH5aBQ9RS4+I71QIF3h3ZT2XK4VzfIZrfjIX1PSp ZqlVSfA/ws0iM4FeKJAiAk7paq5XzBbkS44d8Gbzw9I9YOGZf1HBwHB4X8MQmkyef+ER iTXcdKErNd5iZOjw1TCwWBvYUwarIp1xzPh7yUoZ335BwJH6choEHfRe9RRMyfn6PEv+ mOKc3a08ZKKGqwrwmiktYJyNYNcM0rt713ULvP25/Bq1HDaUdST31X50DG8vwlwWzwj2 87tOP88SN/1J0Xa6d3YgpioLz9wgKK0H6VgdXw/Lqn6CAZk6H6/qvenUHURDsBQ+gGFF ck0w== 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 g30si5692692pgl.9.2019.04.25.01.01.39; Thu, 25 Apr 2019 01:01:56 -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 S2388725AbfDYC6i (ORCPT + 99 others); Wed, 24 Apr 2019 22:58:38 -0400 Received: from mga01.intel.com ([192.55.52.88]:4996 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388683AbfDYC6i (ORCPT ); Wed, 24 Apr 2019 22:58:38 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2019 19:58:36 -0700 X-IronPort-AV: E=Sophos;i="5.60,392,1549958400"; d="scan'208";a="137227848" Received: from likexu-mobl1.ccr.corp.intel.com (HELO [10.239.196.186]) ([10.239.196.186]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/AES128-SHA; 24 Apr 2019 19:58:36 -0700 Subject: Re: [PATCH] KVM: x86: Add Intel CPUID.1F cpuid emulation support To: Sean Christopherson Cc: kvm@vger.kernel.org, Paolo Bonzini , Thomas Gleixner , Len Brown , linux-kernel@vger.kernel.org References: <1555915234-2536-1-git-send-email-like.xu@linux.intel.com> <20190424143238.GB18442@linux.intel.com> From: Like Xu Organization: Intel OTC Message-ID: Date: Thu, 25 Apr 2019 10:58:34 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190424143238.GB18442@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/4/24 22:32, Sean Christopherson wrote: > 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 >> --- >> 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. You're right and the cpuid.1f.eax check is unreliable after I checked a few machines. > >> + >> + 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 agree with this and ecx[15:8] makes sense. > > 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. If it's true, let's skip the vendor check. // I have to mention that AMD already has MCP CPUs. > >> +} >> + >> #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)); Based on: ECX Bits 07 - 00: Level number. Same value in ECX input. Bits 15 - 08: Level type. Bits 31 - 16: Reserved. how about using an increasing order: entry->eax = min(entry->eax, (u32)(f_intel_pt ? 0x14 : 0xd)); // ... more checks when eax is between 0x14 and 0x1f if any /* Check if the host cpu has multi-chip packaging technology.*/ if (((cpuid_ecx(0x1f) >> 8) & 0xff) != 0) entry->eax = 0x1f; // ... more checks when eax greater than 0x1f if any are we OK with it? >> 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 >> >