On 26/10/2015 23:31, Laszlo Ersek wrote: > > If QEMU could evaluate the AP state and not send an SMI to an AP in > > Wait-forSIPI, then updating SMIs to broadcast to all AP should work > > for SeaBios and OVMF.
Yup, this has to be fixed in both QEMU and KVM (separately). I'm not 100% sure of how the bug happens in KVM, because KVM does something really weird (and unintended). The vCPU _is_ in SMM, but it doesn't start running. When you get the next SIPI, the vCPU runs the startup vector in SMM rather than real mode. Still has to be fixed, of course. > > All APs in SeaBios are in Wait-for-SIPI, so > > the BSP will be the only CPU that receives the SMI. In OVMF, all APs > > can be in the HLT loop that Jeff Fan provided a patch for (and I see > > you have a good update for), so the SMI can be delivered to BSP and > > all APs. > > I'd like to run this idea by Paolo (CC'd). Theoretically I might be able > to respin my QEMU patch so that it looks at the APs' states right when > one of the VCPUs writes to APM_CNT. But, as far as I recall, in QEMU it > is two separate actions to generate / make an interrupt pending, and > then to deliver it. Filtering out the SMI at generation time might not > be the right thing to do. Doing it in the delivery / injection code > seems possible, but that code is super quirky and I don't dare touch it. > (Worse, I think that code might exist separately for TCG (in QEMU) and > KVM (in the host kernel).) I'm not sure where it's better to filter it out. I'll have to look a bit more at the code. Paolo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
