From: Sean Christopherson <sean.j.christopherson@intel.com>
To: "Kang, Luwei" <luwei.kang@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"vkuznets@redhat.com" <vkuznets@redhat.com>,
"wanpengli@tencent.com" <wanpengli@tencent.com>,
"jmattson@google.com" <jmattson@google.com>,
"joro@8bytes.org" <joro@8bytes.org>
Subject: Re: [PATCH] KVM: VMX: Disable Intel PT before VM-entry
Date: Mon, 30 Mar 2020 10:21:52 -0700 [thread overview]
Message-ID: <20200330172152.GE24988@linux.intel.com> (raw)
In-Reply-To: <82D7661F83C1A047AF7DC287873BF1E1738A9724@SHSMSX104.ccr.corp.intel.com>
On Mon, Mar 23, 2020 at 02:20:01AM -0700, Kang, Luwei wrote:
> > On Wed, Mar 18, 2020 at 11:48:18AM +0800, Luwei Kang wrote:
> > > If the logical processor is operating with Intel PT enabled (
> > > IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the “load
> > > IA32_RTIT_CTL” VM-entry control must be 0(SDM 26.2.1.1).
> > >
> > > The first disabled the host Intel PT(Clear TraceEn) will make all the
> > > buffered packets are flushed out of the processor and it may cause an
> > > Intel PT PMI. The host Intel PT will be re-enabled in the host Intel
> > > PT PMI handler.
> > >
> > > handle_pmi_common()
> > > -> intel_pt_interrupt()
> > > -> pt_config_start()
> >
> > IIUC, this is only possible when PT "plays nice" with VMX, correct?
> > Otherwise pt->vmx_on will be true and pt_config_start() would skip the
> > WRMSR.
> >
> > And IPT PMI must be delivered via NMI (though maybe they're always
> > delivered via NMI?).
> >
> > In any case, redoing WRMSR doesn't seem safe, and it certainly isn't
> > performant, e.g. what prevents the second WRMSR from triggering a second
> > IPT PMI?
> >
> > pt_guest_enter() is called after the switch to the vCPU has already been
> > recorded, can't this be handled in the IPT code, e.g. something like this?
> >
> > diff --git a/arch/x86/events/intel/pt.c b/arch/x86/events/intel/pt.c index
> > 1db7a51d9792..e38ddae9f0d1 100644
> > --- a/arch/x86/events/intel/pt.c
> > +++ b/arch/x86/events/intel/pt.c
> > @@ -405,7 +405,7 @@ static void pt_config_start(struct perf_event *event)
> > ctl |= RTIT_CTL_TRACEEN;
> > if (READ_ONCE(pt->vmx_on))
> > perf_aux_output_flag(&pt->handle, PERF_AUX_FLAG_PARTIAL);
> > - else
> > + else (!(current->flags & PF_VCPU))
> > wrmsrl(MSR_IA32_RTIT_CTL, ctl);
>
> Intel PT can work in SYSTEM and HOST_GUEST mode by setting the kvm-intel.ko
> parameter "pt_mode". In SYSTEM mode, the host and guest PT trace will be
> saved in the host buffer. The KVM do nothing during VM-entry/exit in SYSTEM
> mode and Intel PT PMI may happened on any place. The PT trace may be disabled
> when running in KVM(PT only needs to be disabled before VM-entry in
> HOST_GUEST mode).
Ah, right. What about enhancing intel_pt_handle_vmx() and 'struct pt' to
replace vmx_on with a field that incorporates the KVM mode? From an
outsider's perspective, that'd be an improvment irrespective of this bug
fix as 'vmx_on' is misleading, e.g. it can be %false when the CPU is post-
VMXON, and really means "post-VMXON and Intel PT can't trace it".
next prev parent reply other threads:[~2020-03-30 17:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 3:48 [PATCH] KVM: VMX: Disable Intel PT before VM-entry Luwei Kang
2020-03-18 15:48 ` Sean Christopherson
2020-03-19 6:13 ` Kang, Luwei
2020-03-23 9:20 ` Kang, Luwei
2020-03-30 17:21 ` Sean Christopherson [this message]
2020-03-31 3:29 ` Kang, Luwei
2020-04-09 18:34 ` Sean Christopherson
2020-04-16 14:14 ` Paolo Bonzini
2020-04-17 1:49 ` Kang, Luwei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200330172152.GE24988@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luwei.kang@intel.com \
--cc=pbonzini@redhat.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox