Re: [edk2] [PATCH 11/58] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER
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
Re: [edk2] [PATCH 11/58] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER
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? Paolo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 11/58] OvmfPkg: implement EFI_SMM_CONTROL2_PROTOCOL with a DXE_RUNTIME_DRIVER
The EFI_SMM_COMMUNICATION_PROTOCOL implementation that is provided by the SMM core depends on EFI_SMM_CONTROL2_PROTOCOL; see the mSmmControl2-Trigger() call in the SmmCommunicationCommunicate() function [MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c]. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek ler...@redhat.com --- OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf | 63 ++ OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c | 224 OvmfPkg/OvmfPkgIa32.dsc | 1 + OvmfPkg/OvmfPkgIa32.fdf | 1 + OvmfPkg/OvmfPkgIa32X64.dsc| 1 + OvmfPkg/OvmfPkgIa32X64.fdf| 1 + OvmfPkg/OvmfPkgX64.dsc| 1 + OvmfPkg/OvmfPkgX64.fdf| 1 + 8 files changed, 293 insertions(+) diff --git a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf new file mode 100644 index 000..a363ee8 --- /dev/null +++ b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf @@ -0,0 +1,63 @@ +## @file +# A DXE_RUNTIME_DRIVER providing synchronous SMI activations via the +# EFI_SMM_CONTROL2_PROTOCOL. +# +# We expect the PEI phase to have covered the following: +# - ensure that the underlying QEMU machine type be Q35 +# (responsible: OvmfPkg/SmmAccess/SmmAccessPei.inf) +# - ensure that the ACPI PM IO space be configured +# (responsible: OvmfPkg/PlatformPei/PlatformPei.inf) +# +# Our own entry point is responsible for confirming the SMI feature and for +# configuring it. +# +# Copyright (C) 2013, 2015, Red Hat, Inc. +# +# This program and the accompanying materials are licensed and made available +# under the terms and conditions of the BSD License which accompanies this +# distribution. The full text of the license may be found at +# http://opensource.org/licenses/bsd-license.php +# +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, WITHOUT +# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +# +## + +[Defines] + INF_VERSION= 0x00010005 + BASE_NAME = SmmControl2Dxe + FILE_GUID = 1206F7CA-A475-4624-A83E-E6FC9BB38E49 + MODULE_TYPE= DXE_RUNTIME_DRIVER + VERSION_STRING = 1.0 + PI_SPECIFICATION_VERSION = 0x00010400 + ENTRY_POINT= SmmControl2DxeEntryPoint + +# +# The following information is for reference only and not required by the build tools. +# +# VALID_ARCHITECTURES = IA32 X64 +# + +[Sources] + SmmControl2Dxe.c + +[Packages] + MdePkg/MdePkg.dec + OvmfPkg/OvmfPkg.dec + +[LibraryClasses] + DebugLib + IoLib + PcdLib + PciLib + UefiBootServicesTableLib + UefiDriverEntryPoint + +[Protocols] + gEfiSmmControl2ProtocolGuid # PROTOCOL ALWAYS_PRODUCED + +[FeaturePcd] + gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire + +[Depex] + TRUE diff --git a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c new file mode 100644 index 000..8036e26 --- /dev/null +++ b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c @@ -0,0 +1,224 @@ +/** @file + + A DXE_RUNTIME_DRIVER providing synchronous SMI activations via the + EFI_SMM_CONTROL2_PROTOCOL. + + We expect the PEI phase to have covered the following: + - ensure that the underlying QEMU machine type be Q35 +(responsible: OvmfPkg/SmmAccess/SmmAccessPei.inf) + - ensure that the ACPI PM IO space be configured +(responsible: OvmfPkg/PlatformPei/PlatformPei.inf) + + Our own entry point is responsible for confirming the SMI feature and for + configuring it. + + Copyright (C) 2013, 2015, Red Hat, Inc.BR + Copyright (c) 2009 - 2010, Intel Corporation. All rights reserved.BR + + This program and the accompanying materials are licensed and made available + under the terms and conditions of the BSD License which accompanies this + distribution. The full text of the license may be found at + http://opensource.org/licenses/bsd-license.php + + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN AS IS BASIS, WITHOUT + WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. + +**/ + +#include IndustryStandard/Q35MchIch9.h +#include Library/DebugLib.h +#include Library/IoLib.h +#include Library/PcdLib.h +#include Library/PciLib.h +#include Library/UefiBootServicesTableLib.h +#include Protocol/SmmControl2.h + +/** + Invokes SMI activation from either the preboot or runtime environment. + + This function generates an SMI. + + @param[in] ThisThe EFI_SMM_CONTROL2_PROTOCOL instance. + @param[in,out] CommandPort The value written to the command port. + @param[in,out] DataPortThe value written to the data port. + @param[in] PeriodicOptional mechanism to engender a periodic + stream. + @param[in] ActivationInterval Optional parameter to repeat at this + period one time
