Re: [PATCH 2/3] KVM: x86: Register Processor Trace interrupt hook iff PT enabled in guest

From: Sean Christopherson
Date: Wed Aug 25 2021 - 11:00:06 EST


On Wed, Aug 25, 2021, Like Xu wrote:
> On 24/8/2021 3:37 am, Sean Christopherson wrote:
> > @@ -11061,6 +11061,8 @@ int kvm_arch_hardware_setup(void *opaque)
> > memcpy(&kvm_x86_ops, ops->runtime_ops, sizeof(kvm_x86_ops));
> > kvm_ops_static_call_update();
> > + if (ops->intel_pt_intr_in_guest && ops->intel_pt_intr_in_guest())
> > + kvm_guest_cbs.handle_intel_pt_intr = kvm_handle_intel_pt_intr;
>
> Emm, it's still buggy.
>
> The guest "unknown NMI" from the host Intel PT can still be reproduced
> after the following operation:
>
> rmmod kvm_intel
> modprobe kvm-intel pt_mode=1 ept=1
> rmmod kvm_intel
> modprobe kvm-intel pt_mode=1 ept=0
>
> Since the handle_intel_pt_intr is not reset to NULL in kvm_arch_hardware_unsetup(),
> and the previous function pointer still exists in the generic KVM data structure.

Ooof, good catch. Any preference between nullifying handle_intel_pt_intr in
setup() vs. unsetup()? I think I like the idea of "unwinding" during unsetup(),
even though it splits the logic a bit.

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b5ade47dad9c..ffc6c2d73508 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11093,6 +11093,7 @@ int kvm_arch_hardware_setup(void *opaque)
void kvm_arch_hardware_unsetup(void)
{
perf_unregister_guest_info_callbacks(&kvm_guest_cbs);
+ kvm_guest_cbs.handle_intel_pt_intr = NULL;

static_call(kvm_x86_hardware_unsetup)();
}


vs.


diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b5ade47dad9c..462aa7a360e9 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -11063,6 +11063,8 @@ int kvm_arch_hardware_setup(void *opaque)

if (ops->intel_pt_intr_in_guest && ops->intel_pt_intr_in_guest())
kvm_guest_cbs.handle_intel_pt_intr = kvm_handle_intel_pt_intr;
+ else
+ kvm_guest_cbs.handle_intel_pt_intr = NULL;
perf_register_guest_info_callbacks(&kvm_guest_cbs);

if (!kvm_cpu_cap_has(X86_FEATURE_XSAVES))

> But I have to say that this fix is much better than the one I proposed [1].
>
> [1] https://lore.kernel.org/lkml/20210514084436.848396-1-like.xu@xxxxxxxxxxxxxxx/
>
> > perf_register_guest_info_callbacks(&kvm_guest_cbs);
> > if (!kvm_cpu_cap_has(X86_FEATURE_XSAVES))
> >