From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jim Mattson <jmattson@google.com>
Cc: Nadav Amit <nadav.amit@gmail.com>,
Aaron Lewis <aaronlewis@google.com>,
kvm list <kvm@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Liran Alon <liran.alon@oracle.com>
Subject: Re: [kvm-unit-tests PATCH v3] x86: Add RDTSC test
Date: Mon, 27 Jan 2020 12:56:06 -0800 [thread overview]
Message-ID: <20200127205606.GC2523@linux.intel.com> (raw)
In-Reply-To: <CALMp9eQYS3W5_PB8wP36UBBGHRHSoJmBDUEJ95AUcXYQ1sC9mQ@mail.gmail.com>
On Mon, Jan 27, 2020 at 11:24:31AM -0800, Jim Mattson wrote:
> On Sun, Jan 26, 2020 at 8:36 PM Nadav Amit <nadav.amit@gmail.com> wrote:
> >
> > > On Jan 26, 2020, at 2:06 PM, Jim Mattson <jmattson@google.com> wrote:
> > >
> > > If I had to guess, you probably have SMM malware on your host. Remove
> > > the malware, and the test should pass.
> >
> > Well, malware will always be an option, but I doubt this is the case.
>
> Was my innuendo too subtle? I consider any code executing in SMM to be malware.
SMI complications seem unlikely. The straw that broke the camel's back
was a 1152 cyle delta, presumably the other failing runs had similar deltas.
I've never benchmarked SMI+RSM, but I highly doubt it comes anywhere close
to VM-Enter/VM-Exit's super optimized ~400 cycle round trip. E.g. I
wouldn't be surprised if just SMI+RSM is over 1500 cycles.
> > Interestingly, in the last few times the failure did not reproduce. Yet,
> > thinking about it made me concerned about MTRRs configuration, and that
> > perhaps performance is affected by memory marked as UC after boot, since
> > kvm-unit-test does not reset MTRRs.
> >
> > Reading the variable range MTRRs, I do see some ranges marked as UC (most of
> > the range 2GB-4GB, if I read the MTRRs correctly):
> >
> > MSR 0x200 = 0x80000000
> > MSR 0x201 = 0x3fff80000800
> > MSR 0x202 = 0xff000005
> > MSR 0x203 = 0x3fffff000800
> > MSR 0x204 = 0x38000000000
> > MSR 0x205 = 0x3f8000000800
> >
> > Do you think we should set the MTRRs somehow in KVM-unit-tests? If yes, can
> > you suggest a reasonable configuration?
>
> I would expect MTRR issues to result in repeatable failures. For
> instance, if your VMCS ended up in UC memory, that might slow things
> down quite a bit. But, I would expect the VMCS to end up at the same
> address each time the test is run.
Agreed on the repeatable failures part, but putting the VMCS in UC memory
shouldn't affect this type of test. The CPU's internal VMCS cache isn't
coherent, and IIRC isn't disabled if the MTRRs for the VMCS happen to be
UC.
next prev parent reply other threads:[~2020-01-27 20:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-02 20:43 [kvm-unit-tests PATCH v3] x86: Add RDTSC test Aaron Lewis
2019-12-03 1:51 ` Liran Alon
2019-12-04 11:48 ` Paolo Bonzini
2020-01-24 23:13 ` Nadav Amit
2020-01-24 23:38 ` Sean Christopherson
2020-01-25 0:06 ` Nadav Amit
2020-01-26 22:06 ` Jim Mattson
2020-01-27 4:36 ` Nadav Amit
2020-01-27 19:24 ` Jim Mattson
2020-01-27 20:56 ` Sean Christopherson [this message]
2020-01-28 17:59 ` Jim Mattson
2020-01-28 18:32 ` Nadav Amit
2020-01-28 18:33 ` Sean Christopherson
2020-01-28 18:42 ` Nadav Amit
2020-01-28 18:43 ` Jim Mattson
2020-01-28 19:03 ` Nadav Amit
2020-01-28 19:34 ` Jim Mattson
2020-01-25 9:43 ` Paolo Bonzini
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=20200127205606.GC2523@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=aaronlewis@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=liran.alon@oracle.com \
--cc=nadav.amit@gmail.com \
--cc=pbonzini@redhat.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