On 03/14/16 10:51, Ni, Ruiyu wrote: > 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.
QEMU implements the AMD specification for the SMM state save area. Please refer to "OvmfPkg/Library/SmmCpuFeaturesLib" (contributed by Paolo -- I can't thank enough for it, whenever it comes up!). ... Sorry if my earlier replies appeared a bit rough, I didn't mean it, I'm just exhausted. Thanks! Laszlo > > Regards, > Ray > > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Laszlo Ersek >> Sent: Monday, March 14, 2016 4:40 PM >> To: Ni, Ruiyu <ruiyu...@intel.com>; Justen, Jordan L >> <jordan.l.jus...@intel.com> >> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org> >> 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:ler...@redhat.com] >>>> Sent: Monday, March 14, 2016 4:11 PM >>>> To: Ni, Ruiyu <ruiyu...@intel.com>; Justen, Jordan L >>>> <jordan.l.jus...@intel.com> >>>> Cc: edk2-devel@lists.01.org <edk2-de...@ml01.01.org>; Gerd Hoffmann >>>> <kra...@redhat.com> >>>> 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 >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
