linux-kernel - Re: [PATCH 6/6] KVM: x86: Add requested index to the CPUID tracepoint

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <00827dc7-3338-ce1a-923a-784284cb26db@web.de>
Date:   Sat, 7 Mar 2020 10:48:25 +0100
From:   Jan Kiszka <jan.kiszka@....de>
To:     Sean Christopherson <sean.j.christopherson@...el.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     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>
Subject: Re: [PATCH 6/6] KVM: x86: Add requested index to the CPUID tracepoint

On 02.03.20 20:57, Sean Christopherson wrote:
> Output the requested index when tracing CPUID emulation; it's basically
> mandatory for leafs where the index is meaningful, and is helpful for
> verifying KVM correctness even when the index isn't meaningful, e.g. the
> trace for a Linux guest's hypervisor_cpuid_base() probing appears to
> be broken (returns all zeroes) at first glance, but is correct because
> the index is non-zero, i.e. the output values correspond to random index
> in the maximum basic leaf.
>
> Suggested-by: Xiaoyao Li <xiaoyao.li@...el.com>
> Cc: Jan Kiszka <jan.kiszka@...mens.com>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@...el.com>
> ---
>   arch/x86/kvm/cpuid.c |  3 ++-
>   arch/x86/kvm/trace.h | 13 ++++++++-----
>   2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index b0a4f3c17932..a3c9f6bf43f3 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -1047,7 +1047,8 @@ void kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx,
>   			}
>   		}
>   	}
> -	trace_kvm_cpuid(function, *eax, *ebx, *ecx, *edx, exact_entry_exists);
> +	trace_kvm_cpuid(function, index, *eax, *ebx, *ecx, *edx,
> +			exact_entry_exists);
>   }
>   EXPORT_SYMBOL_GPL(kvm_cpuid);
>
> diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
> index f194dd058470..aa372d0119f0 100644
> --- a/arch/x86/kvm/trace.h
> +++ b/arch/x86/kvm/trace.h
> @@ -151,12 +151,14 @@ TRACE_EVENT(kvm_fast_mmio,
>    * Tracepoint for cpuid.
>    */
>   TRACE_EVENT(kvm_cpuid,
> -	TP_PROTO(unsigned int function, unsigned long rax, unsigned long rbx,
> -		 unsigned long rcx, unsigned long rdx, bool found),
> -	TP_ARGS(function, rax, rbx, rcx, rdx, found),
> +	TP_PROTO(unsigned int function, unsigned int index, unsigned long rax,
> +		 unsigned long rbx, unsigned long rcx, unsigned long rdx,
> +		 bool found),
> +	TP_ARGS(function, index, rax, rbx, rcx, rdx, found),
>
>   	TP_STRUCT__entry(
>   		__field(	unsigned int,	function	)
> +		__field(	unsigned int,	index		)
>   		__field(	unsigned long,	rax		)
>   		__field(	unsigned long,	rbx		)
>   		__field(	unsigned long,	rcx		)
> @@ -166,6 +168,7 @@ TRACE_EVENT(kvm_cpuid,
>
>   	TP_fast_assign(
>   		__entry->function	= function;
> +		__entry->index		= index;
>   		__entry->rax		= rax;
>   		__entry->rbx		= rbx;
>   		__entry->rcx		= rcx;
> @@ -173,8 +176,8 @@ TRACE_EVENT(kvm_cpuid,
>   		__entry->found		= found;
>   	),
>
> -	TP_printk("func %x rax %lx rbx %lx rcx %lx rdx %lx, cpuid entry %s",
> -		  __entry->function, __entry->rax,
> +	TP_printk("func %x idx %x rax %lx rbx %lx rcx %lx rdx %lx, cpuid entry %s",
> +		  __entry->function, __entry->index, __entry->rax,
>   		  __entry->rbx, __entry->rcx, __entry->rdx,
>   		  __entry->found ? "found" : "not found")
>   );
>

What happened to this patch in your v2 round?

Jan