> 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.
