I don't know of any relevant hardware errata. The test verifies that the implementation adheres to the architectural specification. KVM clearly doesn't adhere to the architectural specification. I don't know what is wrong with your Broadwell machine. On Mon, Oct 12, 2020 at 9:47 AM Nadav Amit <nadav.amit@xxxxxxxxx> wrote: > > > On Oct 12, 2020, at 9:32 AM, Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > > > On Sat, Oct 10, 2020 at 01:42:26AM -0700, Nadav Amit wrote: > >>> On May 8, 2020, at 1:39 PM, Jim Mattson <jmattson@xxxxxxxxxx> wrote: > >>> > >>> When the VMX-preemption timer is activated, code executing in VMX > >>> non-root operation should never be able to record a TSC value beyond > >>> the deadline imposed by adding the scaled VMX-preemption timer value > >>> to the first TSC value observed by the guest after VM-entry. > >>> > >>> Signed-off-by: Jim Mattson <jmattson@xxxxxxxxxx> > >>> Reviewed-by: Peter Shier <pshier@xxxxxxxxxx> > >> > >> This test failed on my bare-metal machine (Broadwell): > >> > >> Test suite: vmx_preemption_timer_expiry_test > >> FAIL: Last stored guest TSC (44435478250637180) < TSC deadline (44435478250419552) > >> > >> Any hints why, perhaps based on the motivation for the test? > > > > This test also fails intermittently on my Haswell and Coffee Lake systems when > > running on KVM. I haven't done any "debug" beyond a quick glance at the test. > > > > The intent of the test is to verify that KVM injects preemption timer VM-Exits > > without violating the architectural guarantees of the timer, e.g. that the exit > > isn't delayed by something else happening in the system. > > Thanks for testing it. I was wondering how come KVM does not experience such > failures. > > I figured the basic motivation of the patch, but I was wondering whether > there is some errata that the test is supposed to check. >
