Messages in this thread | | | Date | Tue, 16 Apr 2024 16:57:42 -0400 | Subject | Re: [PATCH] KVM/x86: Do not clear SIPI while in SMM | From | boris.ostrovsky@oracle ... |
| |
On 4/16/24 4:53 PM, Paolo Bonzini wrote: > On 4/16/24 22:47, Boris Ostrovsky wrote: >> When a processor is running in SMM and receives INIT message the >> interrupt >> is left pending until SMM is exited. On the other hand, SIPI, which >> typically follows INIT, is discarded. This presents a problem since >> sender >> has no way of knowing that its SIPI has been dropped, which results in >> processor failing to come up. >> >> Keeping the SIPI pending avoids this scenario. > > This is incorrect - it's yet another ugly legacy facet of x86, but we > have to live with it. SIPI is discarded because the code is supposed > to retry it if needed ("INIT-SIPI-SIPI").
I couldn't find in the SDM/APM a definitive statement about whether SIPI is supposed to be dropped.
> > The sender should set a flag as early as possible in the SIPI code so > that it's clear that it was not received; and an extra SIPI is not a > problem, it will be ignored anyway and will not cause trouble if > there's a race. > > What is the reproducer for this? >
Hotplugging/unplugging cpus in a loop, especially if you oversubscribe the guest, will get you there in 10-15 minutes.
Typically (although I think not always) this is happening when OVMF if trying to rendezvous and a processor is missing and is sent an extra SMI.
-boris
| |