[Bug 218267] [Sapphire Rapids][Upstream]Boot up multiple Windows VMs hang

bugzilla-daemon
2024-12-17T03:13:50Z

--- Comment #9 from Chao Gao (chao.gao@intel.com) ---
On Mon, Dec 16, 2024 at 07:08:13PM +0000, bugzilla-daemon@kernel.org wrote:
>https://bugzilla.kernel.org/show_bug.cgi?id=218267
>
>--- Comment #8 from Sean Christopherson (seanjc@google.com) ---
>Thanks Chao!
>
>Until the ucode update is available, I think we can workaround the issue in
>KVM
>by clearing VECTORING_INFO_VALID_MASK _immediately_ after exit, i.e. before
>queueing the event for re-injection, if it should be impossible for the exit
>to
>have occurred while vectoring. I'm not sure I want to carry something like

Yes. I tried a similar workaround (i.e., clearing the "valid" bit only for
EXIT_REASON_MSR_WRITE) and our tests showed that it works well.

Strictly speaking, this issue also impacts those VM exits which may occur
during event delivery. Because they might be reported as occurring during event
delivery even if they didn't. KVM won't notice this, and the guest will receive
an extra event due to event re-injection. I wrote a kselftest to demonstrate
this.

Clearing the valid bit works in practice. And there is no ideal software
workaround for all cases. Disabling APICv or intercepting MOV-to-CR8 can
eliminate the issue, but neither is ideal due to the performance impact.

>this long-term since a ucode fix is imminent, but at the least it can
>hopefully
>unblock end users.
>
>The below uses a fairly conservative list of exits (a false positive could be
>quite painful). A slightly less conservative approach would be to also
>include:
>
>case EXIT_REASON_EXTERNAL_INTERRUPT:

We need to include EXTERNAL_INTERRUPT because we observed it in real workloads
on affected CPUs.

>case EXIT_REASON_TRIPLE_FAULT:
>case EXIT_REASON_INIT_SIGNAL:
>case EXIT_REASON_SIPI_SIGNAL:
>case EXIT_REASON_INTERRUPT_WINDOW:
>case EXIT_REASON_NMI_WINDOW:
>
>as those exits should all be recognized only at instruction boundaries.
>
>Compile tested only...
>
>---

...

>@@ -8487,6 +8549,10 @@ __init int vmx_hardware_setup(void)
> if (!enable_apicv || !cpu_has_vmx_ipiv())
> enable_ipiv = false;
>
>+ if (boot_cpu_data.x86_vfm != INTEL_SAPPHIRERAPIDS_X &&
>+ boot_cpu_data.x86_vfm != INTEL_EMERALDRAPIDS_X)
>+ enable_spr141_erratum_workaround = false;

RaptorLake has the same issue.

https://cdrdv2.intel.com/v1/dl/getContent/740518

>+
> if (cpu_has_vmx_tsc_scaling())
> kvm_caps.has_tsc_control = true;
>
>
>base-commit: 50e5669285fc2586c9f946c1d2601451d77cb49e
>--
>
>--
>You may reply to this email to add a comment.
>
>You are receiving this mail because:
>You are on the CC list for the bug.