[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200317195354.28384-1-sean.j.christopherson@intel.com>
Date: Tue, 17 Mar 2020 12:53:52 -0700
From: Sean Christopherson <sean.j.christopherson@...el.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Sean Christopherson <sean.j.christopherson@...el.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
Wanpeng Li <wanpengli@...cent.com>,
Jim Mattson <jmattson@...gle.com>,
Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, Xiaoyao Li <xiaoyao.li@...el.com>,
Jan Kiszka <jan.kiszka@...mens.com>
Subject: [PATCH 0/2] KVM: x86: CPUID tracepoint enhancements
Two enhancements to the CPUID tracepoint. Patch 01 was originally in the
CPUID ranges series, but I unintentionally dropped it in v2.
The final output looks like:
kvm_cpuid: func 0 idx 0 rax d rbx 68747541 rcx 444d4163 rdx 69746e65, cpuid entry found
kvm_cpuid: func d idx 444d4163 rax 0 rbx 0 rcx 0 rdx 0, cpuid entry not found
kvm_cpuid: func 80000023 idx 1 rax f rbx 240 rcx 0 rdx 0, cpuid entry not found, used max basic
kvm_cpuid: func 80000023 idx 2 rax 100 rbx 240 rcx 0 rdx 0, cpuid entry not found, used max basic
I also considered appending "exact" to the "found" case, which is more
directly what Jan suggested, but IMO "found exact" implies there's also a
"found inexact", which is not true. AIUI, calling out that KVM is using
the max basic leaf values is what's really important to avoid confusion.
Ideally, the function of the max basic leaf would also be displayed, but
doing that without printing garbage for the other cases is a lot of ugly
code for marginal value.
Sean Christopherson (2):
KVM: x86: Add requested index to the CPUID tracepoint
KVM: x86: Add blurb to CPUID tracepoint when using max basic leaf
values
arch/x86/kvm/cpuid.c | 9 ++++++---
arch/x86/kvm/trace.h | 18 ++++++++++++------
2 files changed, 18 insertions(+), 9 deletions(-)
--
2.24.1
Powered by blists - more mailing lists