Laszlo, I am not sure whether it's QEMU 2.5 Windows binary's issue or a generic issue.
The issue is: I changed the EAX to 0x1234ABEF before triggering SMI, the SMI handler uses EfiSmmCpuProtocol.ReadSaveState() but gets an incorrect EAX value. The layout of CpuSaveState is different from what is described in Intel IA32 manual. Seems QEMU specific. The CpuSaveState pointer is correct. I dumped the CpuSaveState content. The SMMBase and SMMRevId is correct. But EAX is incorrect. I will get a binary QEMU 2.5 Linux binary to try tomorrow. Regards, Ray >-----Original Message----- >From: edk2-devel [mailto:[email protected]] On Behalf Of Laszlo >Ersek >Sent: Monday, March 14, 2016 4:40 PM >To: Ni, Ruiyu <[email protected]>; Justen, Jordan L ><[email protected]> >Cc: [email protected] <[email protected]> >Subject: Re: [edk2] Software SMI STS bit is not set when writing port B2 in >QEMU Q35 > >On 03/14/16 09:18, Ni, Ruiyu wrote: >> >> >> Regards, >> Ray >> >> >>> -----Original Message----- >>> From: Laszlo Ersek [mailto:[email protected]] >>> Sent: Monday, March 14, 2016 4:11 PM >>> To: Ni, Ruiyu <[email protected]>; Justen, Jordan L >>> <[email protected]> >>> Cc: [email protected] <[email protected]>; Gerd Hoffmann >>> <[email protected]> >>> Subject: Re: Software SMI STS bit is not set when writing port B2 in QEMU >>> Q35 >>> >>> On 03/14/16 08:30, Ni, Ruiyu wrote: >>>> Laszlo, Jordan, >>>> >>>> When launching QEMU in Q35 target mode, when writing to IO port 0xB2, >>>> >>>> the accordingly SMI STS bit (PmBase + 0x34, BIT5) is not set. >>>> >>>> >>>> >>>> Is it a QEMU's bug? >>> >>> I'd rather call it a "choice". >>> >>>> >>>> I do find comments in OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c: >>>> >>>> SmmControl2DxeClear(): >>>> >>>> ---------------- COMMENTS ------ >>>> >>>> In fact QEMU automatically deasserts CPU_INTERRUPT_SMI in: >>>> >>>> - x86_cpu_exec_interrupt() and >>>> >>>> - kvm_arch_pre_run() >>> >>> I guess that function might be to clear SMI_STS indeed (and possibly >>> other things asserted by an SMI) if there was any need. >> >> I tried to hook a software SMI (triggered by B2) but the handler/callback >> was never called. >> >> I know that when booting to ACPI OS, OS writes to B2 with certain value >> to tell firmware to enable SCI. That is achieved through the software SMI. >> The software SMI handler gets called when a certain value is written to B2. >> I am wondering how that is implemented in OVMF. > >On QEMU, QEMU generates the ACPI tables for the OS to use. The OS >running on QEMU does not directly raise SMIs, because the ACPI tables >that QEMU generates offer no such capability. > >The SMI is only raised through SmmControl2DxeTrigger(), and it only >happens when the runtime variable services that the OS calls need an >SMI, in order to pass control to their privileged parts. > >Writing to 0xB2 directly from the OS (ACPI interpreter or similar) is >not supported. > >Thanks >Laszlo > >_______________________________________________ >edk2-devel mailing list >[email protected] >https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
