On 07/30/15 20:50, Paolo Bonzini wrote: > > > On 28/07/2015 20:44, Laszlo Ersek wrote: >> I have a significant update for this patch. On S3 resume, the APMC_EN >> bit (and other bits) are cleared in SMI_EN (which is necessary, see qemu >> commit be66680e). For the trigger method to work right after S3 resume, >> the APMC_EN bit must be set again (otherwise a working-as-expected OS >> will not be able to use the variable services after S3 resume). >> >> I decided to put the S3 boot script to actual use this time, and I am >> now writing the necessary opcodes to the bootscript in the entry point >> (more precisely, in a protocol notify callback). This way chipset state >> is restored by the time the OS gets the control back. > > Ah, so the lockbox is accessed straight from TSEG to retrieve the S3 > bootscript, without going through the SMM handler?
Exactly. Please see the "EFI_NOT_STARTED" occurrences in [edk2] [PATCH 09/58] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI both code and commit message. See also the last paragraph of the "Variable store and LockBox in SMRAM" section in the OVMF whitepaper, and the Intel whitepaper referenced in there. The PEIM that orchestrates the S3 resume boot path, S3Resume2Pei, has direct access to SMRAM (it can open it and close it as it pleases) because SMRAM has not been locked down yet. So it doesn't need to trigger an SMI, in order to enter SMM, in order to access SMRAM. It looks for EFI_PEI_SMM_COMMUNICATION_PPI, yes, and we provide it with one, but we just say, "hey, EFI_NOT_STARTED yet". Then it goes to PEI_SMM_ACCESS_PPI (which we do implement in full), to open / close SMRAM as appropriate, and it restores the lockbox contents with direct access. (Including the boot script stuff saved in lockbox.) This is not very easy to see, because it is split between S3Resume2Pei and SmmLockBoxPeiLib (which the former links against). *After* the lockboxes are restored, the PEIM locks down SMRAM (again using our PEI_SMM_ACCESS_PPI), and then executes the boot script. Since the OS is soon going to reacquire control, this runtime DXE driver that writes to APM_CNT to raise an SMI must be able to work again. (Ie. APM_CNT should actually trigger an SMI, otherwise the OS will just stare cluelessly at us, when the dependent variable services return error codes.) I could have updated the SmmControl2DxeTrigger() function itself to set APMC_EN in SMI_EN on every call -- SmmControl2Dxe is unaware of an intervening S3 suspend/resume cycle --, but for this use case the boot script felt really appropriate. It now restores a piece of chipset state that relates strongly to a runtime DXE driver, which is practically what the boot script concept was invented for. ... Sorry about over-explaining it; I just got real enthused over your insight! :) Thanks Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel