qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: "Kang, Luwei" <luwei.kang@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"mtosatti@redhat.com" <mtosatti@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Chao Peng <chao.p.peng@linux.intel.com>,
	"pbonzini@redhat.com" <pbonzini@redhat.com>,
	"rth@twiddle.net" <rth@twiddle.net>
Subject: Re: [PATCH v4 2/2] i386: Add support to get/set/migrate Intel Processor Trace feature
Date: Thu, 24 Oct 2019 11:15:36 -0300	[thread overview]
Message-ID: <20191024141536.GU6744@habkost.net> (raw)
In-Reply-To: <82D7661F83C1A047AF7DC287873BF1E17382D885@SHSMSX104.ccr.corp.intel.com>

On Thu, Oct 24, 2019 at 01:36:50PM +0000, Kang, Luwei wrote:
> > > > > > > > > f9f4cd1..097c953 100644
> > > > > > > > > --- a/target/i386/kvm.c
> > > > > > > > > +++ b/target/i386/kvm.c
> > > > > > > > > @@ -1811,6 +1811,25 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
> > > > > > > > >                  kvm_msr_entry_add(cpu, MSR_MTRRphysMask(i), mask);
> > > > > > > > >              }
> > > > > > > > >          }
> > > > > > > > > +        if (env->features[FEAT_7_0_EBX] & CPUID_7_0_EBX_INTEL_PT) {
> > > > > > > > > +            int addr_num = kvm_arch_get_supported_cpuid(kvm_state,
> > > > > > > > > +                                                    0x14,
> > > > > > > > > + 1,
> > > > > > > > > + R_EAX) & 0x7;
> > > > > > > > > +
> > > > > > > > > +            kvm_msr_entry_add(cpu, MSR_IA32_RTIT_CTL,
> > > > > > > > > +                            env->msr_rtit_ctrl);
> > > > > > > > > +            kvm_msr_entry_add(cpu, MSR_IA32_RTIT_STATUS,
> > > > > > > > > +                            env->msr_rtit_status);
> > > > > > > > > +            kvm_msr_entry_add(cpu, MSR_IA32_RTIT_OUTPUT_BASE,
> > > > > > > > > +                            env->msr_rtit_output_base);
> > > > > > > >
> > > > > > > > This causes the following crash on some hosts:
> > > > > > > >
> > > > > > > >   qemu-system-x86_64: error: failed to set MSR 0x560 to 0x0
> > > > > > > >   qemu-system-x86_64: target/i386/kvm.c:2673: kvm_put_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
> > > > > > > >
> > > > > > > > Checking for CPUID_7_0_EBX_INTEL_PT is not enough: KVM has
> > > > > > > > additional conditions that might prevent writing to this MSR
> > > > > > > > (PT_CAP_topa_output && PT_CAP_single_range_output).  This
> > > > > > causes QEMU to crash if some of the conditions aren't met.
> > > > > > > >
> > > > > > > > Writing and reading this MSR (and the ones below) need to be conditional on KVM_GET_MSR_INDEX_LIST.
> > > > > > > >
> > > > > > >
> > > > > > > Hi Eduardo,
> > > > > > >     I found this issue can't be reproduced in upstream source
> > > > > > > code but can be reproduced on RHEL8.1. I haven't got the qemu
> > > > > > > source
> > > > > > code of RHEL8.1. But after adding some trace in KVM, I found the
> > > > > > KVM has reported the complete Intel PT CPUID information to qemu
> > > > > > but the Intel PT CPUID (0x14) is lost when qemu setting the
> > > > > > CPUID
> > > > to KVM (cpuid level is 0xd). It looks like lost the below patch.
> > > > > > >
> > > > > > > commit f24c3a79a415042f6dc195f029a2ba7247d14cac
> > > > > > > Author: Luwei Kang <luwei.kang@intel.com>
> > > > > > > Date:   Tue Jan 29 18:52:59 2019 -0500
> > > > > > >     i386: extended the cpuid_level when Intel PT is enabled
> > > > > > >
> > > > > > >     Intel Processor Trace required CPUID[0x14] but the cpuid_level
> > > > > > >     have no change when create a kvm guest with
> > > > > > >     e.g. "-cpu qemu64,+intel-pt".
> > > > > >
> > > > > > Thanks for the pointer.  This may avoid triggering the bug in
> > > > > > the default configuration, but we still need to make the MSR
> > > > > > writing conditional on KVM_GET_MSR_INDEX_LIST.  Older
> > > > > > machine-types have x-intel-pt-auto-level=off, and the user may
> > > > > > set `level`
> > > > manually.
> > > > >
> > > > > Hi Eduardo,
> > > > > Sorry for a delay reply because my mail filter. I tried with the
> > > > > Q35 machine type and default, all looks work well (With some old
> > > > > cpu type
> > > > > + "intel_pt" also work well).  KVM will check the Intel PT work
> > > > > + mode
> > > > > and HW to decide if Intel PT can be exposed to guest, only
> > > > > extended the CPUID level is useless. If the guest doesn't support
> > > > > Intel PT, any MSR read or write will cause #GP. Please remind me
> > > > > if I lost something.
> > > >
> > > > I understand you have tried q35 and pc, but have you tried with older machine-type versions?
> > > >
> > > > Commit f24c3a79a415 doesn't change behavior on pc-*-3.1 and older, so it only avoids triggering the crash in the default case.
> > > > Doesn't QEMU crash if running:
> > > > "-cpu qemu64,+intel-pt -machine pc-i440fx-3.1"?
> > > >
> > > > KVM rejecting MSR writes when something is missing is correct.
> > > > QEMU trying to write the MSR when something is missing (and crashing because of that) is a bug.
> > >
> > > Hi Eduardo,
> > >     Yes, you are right. Intel PT is only set in leaf 0x7.ebx but leaf 0x14 is lost because of the leaf number still 0xd (should 0x14).
> > >     May I remove the "off" like this?
> > 
> > We can't.  This is necessary to keep guest ABI compatibility.
> > Instead, we need to make QEMU not crash if xlevel is too low, because xlevel can be configured by the user.
> 
> Thanks Eduardo.  But I think it is a little complex for user.
> User found crash but how does he know it need to configure the
> xlevel or others?
> If we want to the old machine type support PT can we add some
> code to extend the level to 0x14? Or old machine type can't
> support PT,  mask off this feature from leaf 0x07.ebx[25]
> directly and output some messages?

I agree it's complex for the user, but let's address this
separately:

the first issue here is the crash: QEMU must not crash if using
(e.g.) "-cpu ...,+intel-pt,xlevel=0x13".  This can't be solved by
making any machine-type changes.

The second issue is usability.  This is hard to fix on old
machine-types because we must keep guest ABI compatibility.

In QEMU 3.1 the results of:
  -machine pc-i440fx-3.1 -cpu qemu64,+intel-pt
was:
  CPUID[0].EAX (level) = 7
  CPUID[7].EBX[25] (intel-pt) = 1

and we can't change the behavior of pc-i440fx-3.1.

Your suggestion of printing a warning is good, though.  We can do
that if intel-pt is enabled and level < 0x14.

> 
> Luwei Kang
> 
> > 
> > >
> > > --- a/hw/i386/pc.c
> > > +++ b/hw/i386/pc.c
> > > @@ -132,7 +132,6 @@ GlobalProperty pc_compat_3_1[] = {
> > >      { "Icelake-Client" "-" TYPE_X86_CPU,      "mpx", "on" },
> > >      { "Icelake-Server" "-" TYPE_X86_CPU,      "mpx", "on" },
> > >      { "Cascadelake-Server" "-" TYPE_X86_CPU, "stepping", "5" },
> > > -    { TYPE_X86_CPU, "x-intel-pt-auto-level", "off" },
> > >  };
> > >  const size_t pc_compat_3_1_len = G_N_ELEMENTS(pc_compat_3_1);
> > >
> > > Thanks,
> > > Luwei Kang
> > >
> > > >
> > > > --
> > > > Eduardo
> > >
> > 
> > --
> > Eduardo
> 

-- 
Eduardo



  reply	other threads:[~2019-10-24 15:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-04 16:48 [Qemu-devel] [PATCH v4 1/2] i386: Add Intel Processor Trace feature support Luwei Kang
2018-03-04 16:48 ` [Qemu-devel] [PATCH v4 2/2] i386: Add support to get/set/migrate Intel Processor Trace feature Luwei Kang
2019-10-12  3:14   ` Eduardo Habkost
2019-10-15 12:51     ` Kang, Luwei
2019-10-15 13:29       ` Eduardo Habkost
2019-10-21  6:02         ` Kang, Luwei
2019-10-22 21:44           ` Eduardo Habkost
2019-10-24 11:22             ` Kang, Luwei
2019-10-24 13:24               ` Eduardo Habkost
2019-10-24 13:36                 ` Kang, Luwei
2019-10-24 14:15                   ` Eduardo Habkost [this message]
2018-03-09 19:10 ` [Qemu-devel] [PATCH v4 1/2] i386: Add Intel Processor Trace feature support Eduardo Habkost
2018-03-12  9:07   ` Kang, Luwei
2018-03-12 16:45     ` Eduardo Habkost
2018-03-13 11:16       ` 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=20191024141536.GU6744@habkost.net \
    --to=ehabkost@redhat.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=luwei.kang@intel.com \
    --cc=mtosatti@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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;
as well as URLs for NNTP newsgroup(s).