linux-kernel - Re: [PATCH] KVM: x86/pt: Do not inject TraceToPAPMI when guest PT isn't supported

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <YK6HsR4QXbVuhZf8@google.com>
Date:   Wed, 26 May 2021 17:38:57 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Like Xu <like.xu@...ux.intel.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org
Subject: Re: [PATCH] KVM: x86/pt: Do not inject TraceToPAPMI when guest PT
 isn't supported

On Fri, May 14, 2021, Like Xu wrote:
> When a PT perf user is running in system-wide mode on the host,
> the guest (w/ pt_mode=0) will warn about anonymous NMIs from
> kvm_handle_intel_pt_intr():
> 
> [   18.126444] Uhhuh. NMI received for unknown reason 10 on CPU 0.
> [   18.126447] Do you have a strange power saving mode enabled?
> [   18.126448] Dazed and confused, but trying to continue
> 
> In this case, these PMIs should be handled by the host PT handler().
> When PT is used in guest-only mode, it's harmless to call host handler.
> 
> Fix: 8479e04e7d("KVM: x86: Inject PMI for KVM guest")

s/Fix/Fixes

> Signed-off-by: Like Xu <like.xu@...ux.intel.com>
> ---
>  arch/x86/events/intel/core.c | 3 +--
>  arch/x86/kvm/x86.c           | 3 +++
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 2521d03de5e0..2f09eb0853de 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -2853,8 +2853,7 @@ static int handle_pmi_common(struct pt_regs *regs, u64 status)
>  		if (unlikely(perf_guest_cbs && perf_guest_cbs->is_in_guest() &&
>  			perf_guest_cbs->handle_intel_pt_intr))
>  			perf_guest_cbs->handle_intel_pt_intr();
> -		else
> -			intel_pt_interrupt();
> +		intel_pt_interrupt();

Would it make sense to instead do something like:

	bool host_pmi = true;

	...

		if (unlikely(perf_guest_cbs && perf_guest_cbs->is_in_guest() &&
			     perf_guest_cbs->handle_intel_pt_intr)
			host_pmi = !perf_guest_cbs->handle_intel_pt_intr();

		if (likely(host_pmi))
			intel_pt_interrupt();
>  	}
>  
>  	/*
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 6529e2023147..6660f3948cea 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8087,6 +8087,9 @@ static void kvm_handle_intel_pt_intr(void)
>  {
>  	struct kvm_vcpu *vcpu = __this_cpu_read(current_vcpu);
>  
> +	if (!guest_cpuid_has(vcpu, X86_FEATURE_INTEL_PT))
> +		return;
> +
>  	kvm_make_request(KVM_REQ_PMI, vcpu);
>  	__set_bit(MSR_CORE_PERF_GLOBAL_OVF_CTRL_TRACE_TOPA_PMI_BIT,
>  			(unsigned long *)&vcpu->arch.pmu.global_status);
> -- 
> 2.31.1
>