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
On 27/10/2015 03:12, Fan, Jeff wrote:
> Yes. On physical hw, Aps will not response SMI if Aps received SMI in
> WFSI state. But Aps will have one pending SMI and will enter into SMM
> once Aps receive Startup IPI.
Interesting... so if the BIOS doesn't do SMBASE relocation, an
INIT-SMI-SIPI
On 10/26/15 14:47, Jeff Fan wrote:
> In original ExitBootService callback function, we will send INIT IPI to all
> APs and place APs into wait-for-sipi state.
Yes.
> However, it prevents APs to
> response any SMI. As a result, SMM BSP needs to do a specified timeout delay
> on each SMI.
These
In original ExitBootService callback function, we will send INIT IPI to all
APs and place APs into wait-for-sipi state. However, it prevents APs to
response any SMI. As a result, SMM BSP needs to do a specified timeout delay
on each SMI.
This fix is to place APs into hlt-loop state to let APs
On 10/26/15 22:59, Kinney, Michael D wrote:
> Laszlo,
>
> If an AP is in Wait-for-SIPI state, then the AP should ignore the
> SMI. One description of this is in Intel(R) 64 and IA-32
> Architectures Software Developer's Manual Volume 3C, Section 34.2.
Thanks for the reference -- upon seeing
Laszlo,
I saw your simple patch to handle this case. Thanks! I will review/feedback it
later.
Yes. On physical hw, Aps will not response SMI if Aps received SMI in WFSI
state. But Aps will have one pending SMI and will enter into SMM once Aps
receive Startup IPI.
Form section "Local APIC
6 matches
Mail list logo
