On Thu, Aug 25, 2022, Xiaoyao Li wrote:
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index d7f8331d6f7e..3e9ce8f600d2 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -38,6 +38,7 @@
> #include <asm/fpu/api.h>
> #include <asm/fpu/xstate.h>
> #include <asm/idtentry.h>
> +#include <asm/intel_pt.h>
> #include <asm/io.h>
> #include <asm/irq_remapping.h>
> #include <asm/kexec.h>
> @@ -1128,13 +1129,19 @@ static void pt_guest_enter(struct vcpu_vmx *vmx)
> if (vmx_pt_mode_is_system())
> return;
>
> + /*
> + * Stop Intel PT on host to avoid vm-entry failure since
> + * VM_ENTRY_LOAD_IA32_RTIT_CTL is set
> + */
> + intel_pt_stop();
> +
> /*
> * GUEST_IA32_RTIT_CTL is already set in the VMCS.
> * Save host state before VM entry.
> */
> rdmsrl(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl);
KVM's manual save/restore of MSR_IA32_RTIT_CTL should be dropped. If PT/RTIT can
trace post-VMXON, then intel_pt_stop() will disable tracing and intel_pt_resume()
will restore the host's desired value.
> if (vmx->pt_desc.guest.ctl & RTIT_CTL_TRACEEN) {
> - wrmsrl(MSR_IA32_RTIT_CTL, 0);
> + /* intel_pt_stop() ensures RTIT_CTL.TraceEn is zero */
> pt_save_msr(&vmx->pt_desc.host, vmx->pt_desc.num_address_ranges);
Isn't this at risk of the same corruption? What prevents a PT NMI that arrives
after this point from changing other RTIT MSRs, thus causing KVM to restore the
wrong values?
> pt_load_msr(&vmx->pt_desc.guest, vmx->pt_desc.num_address_ranges);
> }
> @@ -1156,6 +1163,8 @@ static void pt_guest_exit(struct vcpu_vmx *vmx)
> */
> if (vmx->pt_desc.host.ctl)
> wrmsrl(MSR_IA32_RTIT_CTL, vmx->pt_desc.host.ctl);
> +
> + intel_pt_resume();
> }
>
> void vmx_set_host_fs_gs(struct vmcs_host_state *host, u16 fs_sel, u16 gs_sel,
> --
> 2.27.0
>
