From: Jim Mattson <jmattson@google.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.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 11:24:31 -0800 [thread overview]
Message-ID: <CALMp9eQYS3W5_PB8wP36UBBGHRHSoJmBDUEJ95AUcXYQ1sC9mQ@mail.gmail.com> (raw)
In-Reply-To: <436117EB-5017-4FF0-A89B-16B206951804@gmail.com>
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.
> 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.
> >
> > On Fri, Jan 24, 2020 at 4:06 PM Nadav Amit <nadav.amit@gmail.com> wrote:
> >>> On Jan 24, 2020, at 3:38 PM, Sean Christopherson <sean.j.christopherson@intel.com> wrote:
> >>>
> >>> On Fri, Jan 24, 2020 at 03:13:44PM -0800, Nadav Amit wrote:
> >>>>> On Dec 2, 2019, at 12:43 PM, Aaron Lewis <aaronlewis@google.com> wrote:
> >>>>>
> >>>>> Verify that the difference between a guest RDTSC instruction and the
> >>>>> IA32_TIME_STAMP_COUNTER MSR value stored in the VMCS12's VM-exit
> >>>>> MSR-store list is less than 750 cycles, 99.9% of the time.
> >>>>>
> >>>>> 662f1d1d1931 ("KVM: nVMX: Add support for capturing highest observable L2 TSC”)
> >>>>>
> >>>>> Signed-off-by: Aaron Lewis <aaronlewis@google.com>
> >>>>> Reviewed-by: Jim Mattson <jmattson@google.com>
> >>>>
> >>>> Running this test on bare-metal I get:
> >>>>
> >>>> Test suite: rdtsc_vmexit_diff_test
> >>>> FAIL: RDTSC to VM-exit delta too high in 117 of 100000 iterations
> >>>>
> >>>> Any idea why? Should I just play with the 750 cycles magic number?
> >>>
> >>> Argh, this reminds me that I have a patch for this test to improve the
> >>> error message to makes things easier to debug. Give me a few minutes to
> >>> get it sent out, might help a bit.
> >>
> >> Thanks for the quick response. With this patch I get on my bare-metal Skylake:
> >>
> >> FAIL: RDTSC to VM-exit delta too high in 100 of 49757 iterations, last = 1152
> >> FAIL: Guest didn't run to completion.
> >>
> >> I’ll try to raise the delta and see what happens.
> >>
> >> Sorry for my laziness - it is just that like ~30% of the tests that are
> >> added fail on bare-metal :(
>
>
next prev parent reply other threads:[~2020-01-27 19:24 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 [this message]
2020-01-27 20:56 ` Sean Christopherson
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=CALMp9eQYS3W5_PB8wP36UBBGHRHSoJmBDUEJ95AUcXYQ1sC9mQ@mail.gmail.com \
--to=jmattson@google.com \
--cc=aaronlewis@google.com \
--cc=kvm@vger.kernel.org \
--cc=liran.alon@oracle.com \
--cc=nadav.amit@gmail.com \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.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;
as well as URLs for NNTP newsgroup(s).