From: bugzilla-daemon@kernel.org
To: kvm@vger.kernel.org
Subject: [Bug 216177] kvm-unit-tests vmx has about 60% of failure chance
Date: Tue, 28 Jun 2022 04:39:33 +0000 [thread overview]
Message-ID: <bug-216177-28872-K60n1GdV2D@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-216177-28872@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=216177
--- Comment #8 from Jim Mattson (jmattson@google.com) ---
On Mon, Jun 27, 2022 at 8:54 PM Nadav Amit <nadav.amit@gmail.com> wrote:
> The failure on bare-metal that I experienced hints that this is either a test
> bug or (much less likely) a hardware bug. But I do not think it is likely to
> be
> a KVM bug.
KVM does not use the VMX-preemption timer to virtualize L1's
VMX-preemption timer (and that is why KVM is broken). The KVM bug was
introduced with commit f4124500c2c1 ("KVM: nVMX: Fully emulate
preemption timer"), which uses an L0 CLOCK_MONOTONIC hrtimer to
emulate L1's VMX-preemption timer. There are many reasons that this
cannot possibly work, not the least of which is that the
CLOCK_MONOTONIC timer is subject to time slew.
Currently, KVM reserves L0's VMX-preemption timer for emulating L1's
APIC timer. Better would be to determine whether L1's APIC timer or
L1's VMX-preemption timer is scheduled to fire first, and use L0's
VMX-preemption timer to trigger a VM-exit on the nearest alarm.
Alternatively, as Sean noted, one could perhaps arrange for the
hrtimer to fire early enough that it won't fire late, but I don't
really think that's a viable solution.
I can't explain the bare-metal failures, but I will note that the test
assumes the default treatment of SMIs and SMM. The test will likely
fail with the dual-monitor treatment of SMIs and SMM. Aside from the
older CPUs with broken VMX-preemption timers, I don't know of any
relevant errata.
Of course, it is possible that the test itself is buggy. For the
person who reported bare-metal failures on Ice Lake and Cooper Lake,
how long was the test in VMX non-root mode past the VMX-preemption
timer deadline?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2022-06-28 4:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 2:17 [Bug 216177] New: kvm-unit-tests vmx has about 60% of failure chance bugzilla-daemon
2022-06-28 0:28 ` [Bug 216177] " bugzilla-daemon
2022-06-28 0:37 ` Nadav Amit
2022-06-28 0:37 ` bugzilla-daemon
2022-06-28 1:19 ` bugzilla-daemon
2022-06-28 1:42 ` Nadav Amit
2022-06-28 4:39 ` Jim Mattson
2022-06-28 1:30 ` bugzilla-daemon
2022-06-28 1:42 ` bugzilla-daemon
2022-06-28 1:48 ` bugzilla-daemon
2022-06-28 2:19 ` bugzilla-daemon
2022-06-28 4:39 ` bugzilla-daemon [this message]
2022-06-28 6:11 ` bugzilla-daemon
2022-06-28 18:24 ` Jim Mattson
2022-06-28 18:24 ` bugzilla-daemon
2022-06-29 0:22 ` bugzilla-daemon
2022-06-29 2:32 ` Jim Mattson
2022-06-29 2:32 ` bugzilla-daemon
2022-06-29 2:50 ` bugzilla-daemon
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=bug-216177-28872-K60n1GdV2D@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=kvm@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.