Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp2925005ybf; Mon, 2 Mar 2020 18:50:55 -0800 (PST) X-Google-Smtp-Source: ADFU+vsiUE4pAZpiE6M7+AhcUALSr5CsGnpJzInLYXdXPMPVt7uNWpkixTJe+UBEnhMUDXooMvxM X-Received: by 2002:a9d:34c:: with SMTP id 70mr1692152otv.174.1583203855508; Mon, 02 Mar 2020 18:50:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583203855; cv=none; d=google.com; s=arc-20160816; b=U4VWBx1H3rGBzDbl4ejJYGfZLDwUf657okMexZWQkRgTgnnoR8ho60tY1NJIM1INTG y7sLROKJ+RSMDDZnKONa+uqV1Q64eRPdzZ/y5QhoRpHvEyp3PhJKx/xJLasPN7onK2+8 uD7u9nIqN0LOXUeot3oNSRnDHnbvOpjrrbeX486evWvAmIoVyG0XvBS8B9uoG+1K/RUv e8UQAjwdjnPFD0DBsZK36T0TaehSAr4QRLYBBIn454ybZCgY+MOyBk09FA7PnMh8PCag 9AF27aozxgwTIZTtgMkUo+gq46e39fGatkzDW/xoL8ZphblZbirJ3oqunzc1gVDW5aKD 78jw== 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:from:references:cc:to:subject; bh=xENtf580ZfA9dY4n3rSWEtpebxPHiIep2qJX1GSpdOA=; b=ZSUQVaM1xPyaRSSph0n12OSAeXazXbrHtm33bp93U2/NMeEkTSSmMaV2R9nUs+0jRN DcimBz40jj4E4l71OboOkwXLl67U8T3ryGJiTU5ySUhOfg1sL1/gkAamjjaildEv7uZr yKbD4y/aSYdC0ZuMIHYMx6Ptp61h+P5wmEnwGmgdH6zaNIgIZ0txEnviFNxLTdBNtz8+ hW9jLX3+B8D9n67huTZNJDzVi6auo3C1rAFA8dYrRzrCtNrjAyrnCjkMDsJlF7z3cXhY LZp1Hvet1677v+MSIS8spPUNSupK/v6V2ErHKcamvhHIeW+mt5M9phRSoW0c+h41Ow2H 4Sog== 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 e26si7695388otk.251.2020.03.02.18.50.43; Mon, 02 Mar 2020 18:50:55 -0800 (PST) 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 S1729119AbgCCCuR (ORCPT + 99 others); Mon, 2 Mar 2020 21:50:17 -0500 Received: from mga17.intel.com ([192.55.52.151]:48417 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729082AbgCCCuJ (ORCPT ); Mon, 2 Mar 2020 21:50:09 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2020 18:50:08 -0800 X-IronPort-AV: E=Sophos;i="5.70,509,1574150400"; d="scan'208";a="233439160" Received: from xiaoyaol-mobl.ccr.corp.intel.com (HELO [10.255.30.67]) ([10.255.30.67]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Mar 2020 18:50:05 -0800 Subject: Re: [PATCH 1/6] KVM: x86: Fix tracing of CPUID.function when function is out-of-range To: Sean Christopherson , Paolo Bonzini Cc: Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jan Kiszka References: <20200302195736.24777-1-sean.j.christopherson@intel.com> <20200302195736.24777-2-sean.j.christopherson@intel.com> From: Xiaoyao Li Message-ID: <6b41fc5c-f7f4-b20d-cfb5-95bf13cc7534@intel.com> Date: Tue, 3 Mar 2020 10:50:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200302195736.24777-2-sean.j.christopherson@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 3/3/2020 3:57 AM, Sean Christopherson wrote: > Rework kvm_cpuid() to query entry->function when adjusting the output > values so that the original function (in the aptly named "function") is > preserved for tracing. This fixes a bug where trace_kvm_cpuid() will > trace the max function for a range instead of the requested function if > the requested function is out-of-range and an entry for the max function > exists. > > Fixes: 43561123ab37 ("kvm: x86: Improve emulation of CPUID leaves 0BH and 1FH") > Reported-by: Jan Kiszka > Cc: Jim Mattson > Cc: Xiaoyao Li > Signed-off-by: Sean Christopherson > --- > arch/x86/kvm/cpuid.c | 15 +++++++-------- > 1 file changed, 7 insertions(+), 8 deletions(-) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index b1c469446b07..6be012937eba 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -997,12 +997,12 @@ static bool cpuid_function_in_range(struct kvm_vcpu *vcpu, u32 function) > return max && function <= max->eax; > } > > +/* Returns true if the requested leaf/function exists in guest CPUID. */ > bool kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx, > u32 *ecx, u32 *edx, bool check_limit) > { > - u32 function = *eax, index = *ecx; > + const u32 function = *eax, index = *ecx; > struct kvm_cpuid_entry2 *entry; > - struct kvm_cpuid_entry2 *max; > bool found; > > entry = kvm_find_cpuid_entry(vcpu, function, index); > @@ -1015,18 +1015,17 @@ bool kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx, > */ > if (!entry && check_limit && !guest_cpuid_is_amd(vcpu) && > !cpuid_function_in_range(vcpu, function)) { > - max = kvm_find_cpuid_entry(vcpu, 0, 0); > - if (max) { > - function = max->eax; > - entry = kvm_find_cpuid_entry(vcpu, function, index); > - } > + entry = kvm_find_cpuid_entry(vcpu, 0, 0); > + if (entry) > + entry = kvm_find_cpuid_entry(vcpu, entry->eax, index); There is a problem. when queried leaf is out of range on Intel CPU, it returns the maximum basic leaf, and any dependence on input ECX (i.e., subleaf) value in the basic leaf is honored. As disclaimed in SDM of CPUID instruction. The ECX should be honored if and only the leaf has a significant index. If the leaf doesn't has a significant index, it just ignores the EDX input in bare metal. So it should be something like: if (!entry && check_limit && !guest_cpuid_is_amd(vcpu) && !cpuid_function_in_range(vcpu, function)) { entry = kvm_find_cpuid_entry(vcpu, 0, 0); if (entry) { entry = kvm_find_cpuid_entry(vcpu, entry->eax, 0); if (entry && entry->flags & KVM_CPUID_FLAG_SIGNIFCANT_INDEX ) { entry = kvm_find_cpuid_entry(vcpu, entry->eax, index); } } } > } > if (entry) { > *eax = entry->eax; > *ebx = entry->ebx; > *ecx = entry->ecx; > *edx = entry->edx; > - if (function == 7 && index == 0) { > + > + if (entry->function == 7 && index == 0) { > u64 data; > if (!__kvm_get_msr(vcpu, MSR_IA32_TSX_CTRL, &data, true) && > (data & TSX_CTRL_CPUID_CLEAR)) >