Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp2601284ybf; Mon, 2 Mar 2020 11:58:10 -0800 (PST) X-Google-Smtp-Source: ADFU+vsZaN2Gwful+z75bV5/5ZJJx0PUd41paJlPuS2GbAv2ptghl76rVTP2Md3I8m5F1dCwf/7B X-Received: by 2002:a9d:3c1:: with SMTP id f59mr694327otf.170.1583179090664; Mon, 02 Mar 2020 11:58:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583179090; cv=none; d=google.com; s=arc-20160816; b=DsjuARV1OdQia1e3bPdtpe1F+z7Nx8rJxNS1lwJbg6JZOz6CM4vv23mdJDqPC1oav8 00kNoOy7/Mx5SbHNNPduMXyycVLM2De5a2jRMWvqttLnRtB5GacE1mDqkCM79lemzbAF CWrKV6wNSOW50MXo/U+hlaAeWTKQvT3f71cHwbxHqV0uuJwchqkXBOijgp8y/j37pHWb GBbFBvpBcdW1jcDl0+9RopvvE2ve15Mg/HPSssB57og5Gjdumjistz5QG/7Gzr/xqtq9 kk5Eh40ZJ4GfB0CKkKLjX2g3m/+3nCrf6ozvc0UlOpTjuV9MnhsKG47hfxL91NJ+LJBa dDqw== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=VYry1glaihRIXyuhseWN3xhRWBaDeRdRb1f9fTz4osA=; b=u4I+iKmGtEzHvZTy3sDo2/0qkziDO1Y/3ABUsOcxzSgjaN3QHdX5zxVbo0SEbkGhJq QvSFw1Pv6oaH1J5ofonOdbyFFv/MwJYgFqEf4k4KMEoLs5Vba9se1b8SvQTxmEbtitPm Nvw9jACEoFPPoGagfzEgfJtAt0ynQ4D0YZHIOi+ymad2LPlV0HOfU7lgnaPY0kAdBQgx T5MmYJhXHU+0uB97TI1PF5ppYwYoDx5IbbzR2mXUeK4ryDBA2+8VGb5pzXXppb83QU5I wPrqZcWIHoWbOHNLiwb6oAizs6w4axWhYGoJewjDjtBETkP/mcTq2C0lKdNUL4va/I9/ 2DgA== 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 n14si4507684otr.241.2020.03.02.11.57.58; Mon, 02 Mar 2020 11:58:10 -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 S1726906AbgCBT5m (ORCPT + 99 others); Mon, 2 Mar 2020 14:57:42 -0500 Received: from mga05.intel.com ([192.55.52.43]:30422 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726846AbgCBT5k (ORCPT ); Mon, 2 Mar 2020 14:57:40 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2020 11:57:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,508,1574150400"; d="scan'208";a="438404989" Received: from sjchrist-coffee.jf.intel.com ([10.54.74.202]) by fmsmga005.fm.intel.com with ESMTP; 02 Mar 2020 11:57:39 -0800 From: Sean Christopherson To: Paolo Bonzini Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Jan Kiszka , Xiaoyao Li Subject: [PATCH 5/6] KVM: x86: Rename "found" variable in kvm_cpuid() to "exact_entry_exists" Date: Mon, 2 Mar 2020 11:57:35 -0800 Message-Id: <20200302195736.24777-6-sean.j.christopherson@intel.com> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200302195736.24777-1-sean.j.christopherson@intel.com> References: <20200302195736.24777-1-sean.j.christopherson@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rename "found" in kvm_cpuid() to "exact_entry_exists" to better convey that the intent of the tracepoint's "found/not found" output is to trace whether the output values are for the actual requested leaf or for some other (likely unrelated) leaf that was found while processing entries to emulate funky CPU behavior, e.g. the max basic leaf on Intel CPUs when the requested CPUID leaf is out of range. Suggested-by: Jan Kiszka Signed-off-by: Sean Christopherson --- arch/x86/kvm/cpuid.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 869526930cf7..b0a4f3c17932 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -1002,10 +1002,10 @@ void kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx, { const u32 function = *eax, index = *ecx; struct kvm_cpuid_entry2 *entry; - bool found; + bool exact_entry_exists; entry = kvm_find_cpuid_entry(vcpu, function, index); - found = entry; + exact_entry_exists = !!entry; /* * Intel CPUID semantics treats any query for an out-of-range * leaf as if the highest basic leaf (i.e. CPUID.0H:EAX) were @@ -1047,7 +1047,7 @@ void kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx, } } } - trace_kvm_cpuid(function, *eax, *ebx, *ecx, *edx, found); + trace_kvm_cpuid(function, *eax, *ebx, *ecx, *edx, exact_entry_exists); } EXPORT_SYMBOL_GPL(kvm_cpuid); -- 2.24.1