From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 24 Sep 2019 04:35:12 -0700 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2740E85541; Tue, 24 Sep 2019 11:35:11 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-118.rdu2.redhat.com [10.10.120.118]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2CFB7600CC; Tue, 24 Sep 2019 11:35:07 +0000 (UTC) From: "Laszlo Ersek" To: edk2-devel-groups-io Cc: Ard Biesheuvel , Boris Ostrovsky , Brijesh Singh , Igor Mammedov , Jiewen Yao , Joao M Martins , Jordan Justen , Jun Nakajima , Michael Kinney , Paolo Bonzini , Phillip Goerl , Yingwen Chen Subject: [PATCH wave 1 00/10] support QEMU's "SMRAM at default SMBASE" feature Date: Tue, 24 Sep 2019 13:34:55 +0200 Message-Id: <20190924113505.27272-1-lersek@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 24 Sep 2019 11:35:11 +0000 (UTC) Content-Transfer-Encoding: quoted-printable Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3D1512 Repo: https://github.com/lersek/edk2.git Branch: smram_at_default_smbase_bz_1512_wave_1 This is the firmware-side patch series for the QEMU feature that Igor is proposing in [Qemu-devel] [PATCH 0/2] q35: mch: allow to lock down 128K RAM at default SMBASE address posted at http://mid.mail-archive.com/20190917130708.10281-1-imammedo@redhat.com https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg03538.html https://edk2.groups.io/g/devel/message/47364 This OVMF patch series is supposed to be the first "wave" of patch sets, working towards VCPU hotplug with SMM enabled. We want the hot-plugged VCPU to execute its very first instruction from SMRAM, running in SMM, for protection from OS and PCI DMA interference. In the (long!) discussion at http://mid.mail-archive.com/20190905174503.2acaa46a@redhat.com https://edk2.groups.io/g/devel/message/46910 https://bugzilla.tianocore.org/show_bug.cgi?id=3D1512#c9 we considered diverging from the specs and changing the default SMBASE to an address different from 0x3_0000, so that it would point into SMRAM. However, Igor had the idea to keep the default SMBASE intact, and replace the underlying system RAM (128 KB of it) with lockable SMRAM. This conforms to the language of the Intel SDM, namely, "[t]he actual physical location of the SMRAM can be in system memory or in a separate RAM memory". When firmware locks this QEMU-specific SMRAM, the latter completely disappears from the address space of code that runs outside of SMM (including PCI devices doing DMA). We call the remaining MMIO area a "black hole". The present patch set detects the QEMU feature, locks the SMRAM at the right times, and informs firmware and OS components to stay away form the SMRAM at the default SMBASE. I've tested the set extensively: http://mid.mail-archive.com/c18f1ada-3eca-d5f1-da4f-e74181c5a862@redhat= .com https://edk2.groups.io/g/devel/message/47864 Going forward, if I understand correctly, the plan is to populate the new SMRAM with the hotplug SMI handler. (This would likely be put in place by OvmfPkg/PlatformPei, from NASM source code. The SmmRelocateBases() function in UefiCpuPkg/PiSmmCpuDxeSmm backs up the original contents before, and restores them after, the initial SMBASE relocation of the cold-plugged VCPUs. Thus the hotplug SMI handler would survive the initial relocation of the cold-plugged VCPUs.) Further, when a VCPU is hot-plugged, we seem to intend to raise an SMI for it (perhaps internally to QEMU?), which will remain pending until the VCPU is launched with INIT-SIPI-SIPI. Once the INIT-SIPI-SIPI is sent, the VCPU will immediately enter SMM, and run the SMI handler in the locked SMRAM at the default SMBASE. At RSM, it may continue at the vector requested in the INIT-SIPI-SIPI. Cc: Ard Biesheuvel Cc: Boris Ostrovsky Cc: Brijesh Singh Cc: Igor Mammedov Cc: Jiewen Yao Cc: Joao M Martins Cc: Jordan Justen Cc: Jun Nakajima Cc: Michael Kinney Cc: Paolo Bonzini Cc: Phillip Goerl Cc: Yingwen Chen Thanks Laszlo Laszlo Ersek (10): OvmfPkg: introduce PcdQ35SmramAtDefaultSmbase OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro defs OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macros OvmfPkg/PlatformPei: factor out Q35BoardVerification() OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (skeleton) OvmfPkg/PlatformPei: assert there's no permanent PEI RAM at default SMBASE OvmfPkg/PlatformPei: reserve the SMRAM at the default SMBASE, if it exists OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default SMBASE OvmfPkg/SmmAccess: close and lock SMRAM at default SMBASE OvmfPkg/PlatformPei: detect SMRAM at default SMBASE (for real) OvmfPkg/Include/IndustryStandard/Q35MchIch9.h | 106 ++++++++++= +--------- OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 21 +++- OvmfPkg/Library/SmmCpuFeaturesLib/SmmCpuFeaturesLib.inf | 4 + OvmfPkg/OvmfPkg.dec | 6 ++ OvmfPkg/OvmfPkgIa32.dsc | 1 + OvmfPkg/OvmfPkgIa32X64.dsc | 1 + OvmfPkg/OvmfPkgX64.dsc | 1 + OvmfPkg/PlatformPei/AmdSev.c | 24 ++++- OvmfPkg/PlatformPei/MemDetect.c | 87 ++++++++++= +++--- OvmfPkg/PlatformPei/Platform.c | 24 +++++ OvmfPkg/PlatformPei/Platform.h | 7 ++ OvmfPkg/PlatformPei/PlatformPei.inf | 1 + OvmfPkg/SmmAccess/SmmAccess2Dxe.c | 7 ++ OvmfPkg/SmmAccess/SmmAccess2Dxe.inf | 1 + OvmfPkg/SmmAccess/SmmAccessPei.c | 6 ++ OvmfPkg/SmmAccess/SmmAccessPei.inf | 1 + OvmfPkg/SmmAccess/SmramInternal.c | 25 +++++ OvmfPkg/SmmAccess/SmramInternal.h | 8 ++ 18 files changed, 260 insertions(+), 71 deletions(-) --=20 2.19.1.3.g30247aa5d201