> On Oct 12, 2020, at 11:46 AM, Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > On Mon, Oct 12, 2020 at 11:31 AM Nadav Amit <nadav.amit@xxxxxxxxx> wrote: >>> On Oct 12, 2020, at 11:29 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >>> >>> On 12/10/20 20:17, Nadav Amit wrote: >>>>> KVM clearly doesn't adhere to the architectural specification. I don't >>>>> know what is wrong with your Broadwell machine. >>>> Are you saying that the test is expected to fail on KVM? And that Sean’s >>>> failures are expected? >>> >>> It's not expected to fail, but it's apparently broken. >> >> Hm… Based on my results on bare-metal, it might be an architectural issue or >> a test issue, and not a KVM issue. > > From section 25.5.1 of the SDM, volume 3: > > If the last VM entry was performed with the 1-setting of “activate > VMX-preemption timer” VM-execution control, > the VMX-preemption timer counts down (from the value loaded by VM > entry; see Section 26.7.4) in VMX non- > root operation. When the timer counts down to zero, it stops counting > down and a VM exit occurs (see Section > 25.2). > > The test is actually quite lax, in that it doesn't start tracking VMX > non-root operation time until actually in the guest. Hardware is free > to start tracking VMX non-root operation time during VM-entry. > > If the test can both observe a TSC value after the VMX-preemption > timer deadline *and* store that value to memory, then the store > instruction must have started executing after the VMX-preemption timer > has counted down to zero. Per the SDM, a VM-exit should have occurred > before the store could retire. > > Of course, there could be a test bug. My guess was that TSC_OFFSET is left set by one of the previous tests. But unfortunately, I do not manage to reproduce the failure.
