From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 192.55.52.136, mailfrom: jiewen.yao@intel.com) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by groups.io with SMTP; Thu, 26 Sep 2019 01:46:19 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2019 01:46:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,551,1559545200"; d="scan'208";a="183557846" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga008.jf.intel.com with ESMTP; 26 Sep 2019 01:46:17 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 26 Sep 2019 01:46:17 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 26 Sep 2019 01:46:17 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.113]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.132]) with mapi id 14.03.0439.000; Thu, 26 Sep 2019 16:46:14 +0800 From: "Yao, Jiewen" To: "devel@edk2.groups.io" , "lersek@redhat.com" CC: Ard Biesheuvel , Boris Ostrovsky , Brijesh Singh , "Igor Mammedov" , Joao M Martins , "Justen, Jordan L" , "Nakajima, Jun" , "Kinney, Michael D" , Paolo Bonzini , Phillip Goerl , "Chen, Yingwen" Subject: Re: [edk2-devel] [PATCH wave 1 00/10] support QEMU's "SMRAM at default SMBASE" feature Thread-Topic: [edk2-devel] [PATCH wave 1 00/10] support QEMU's "SMRAM at default SMBASE" feature Thread-Index: AQHVcswuTs7uyCalfkWjfFZucV6aH6c9ppXA Date: Thu, 26 Sep 2019 08:46:14 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F7C9D2F@shsmsx102.ccr.corp.intel.com> References: <20190924113505.27272-1-lersek@redhat.com> In-Reply-To: <20190924113505.27272-1-lersek@redhat.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMjhiY2Y0NjYtNDYxZi00ZmFhLWFiYTctM2RjYzAxNWViMGQwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRUUzOTUrdlFCN2h3ZUxKc3NOMXkxQnFURTZOM0E0K3kyODNYWWk2Tk92UG1KRE5ReE4yZyt3NXkyS1ZUN0pIcyJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: jiewen.yao@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Laszlo May I know if you want to support legacy BIOS? The legacy BIOS memory map is reported in E820, which is different with UEF= I memory map. In OvmfPkg\Csm\LegacyBiosDxe\LegacyBootSupport.c, LegacyBiosBuildE820() wil= l hardcode below 640K address to be OS usage without consulting UEFI memory= map. // // First entry is 0 to (640k - EBDA) // ACCESS_PAGE0_CODE ( E820Table[0].BaseAddr =3D 0; E820Table[0].Length =3D (UINT64) ((*(UINT16 *) (UINTN)0x40E) << 4); E820Table[0].Type =3D EfiAcpiAddressRangeMemory; ); If we want to support this feature in legacy BIOS, we also need reserve the= black hole here. Thank you Yao Jiewen > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Laszlo Ers= ek > Sent: Tuesday, September 24, 2019 7:35 PM > To: edk2-devel-groups-io > Cc: Ard Biesheuvel ; Boris Ostrovsky > ; Brijesh Singh ; Igor > Mammedov ; Yao, Jiewen ; > Joao M Martins ; Justen, Jordan L > ; Nakajima, Jun ; Kinn= ey, > Michael D ; Paolo Bonzini > ; Phillip Goerl ; Chen, > Yingwen > Subject: [edk2-devel] [PATCH wave 1 00/10] support QEMU's "SMRAM at > default SMBASE" feature >=20 > 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 >=20 > This is the firmware-side patch series for the QEMU feature that Igor is > proposing in >=20 > [Qemu-devel] [PATCH 0/2] > q35: mch: allow to lock down 128K RAM at default SMBASE address >=20 > posted at >=20 > 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 >=20 > This OVMF patch series is supposed to be the first "wave" of patch sets, > working towards VCPU hotplug with SMM enabled. >=20 > 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 >=20 > 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 >=20 > 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". >=20 > 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. >=20 > I've tested the set extensively: >=20 > http://mid.mail-archive.com/c18f1ada-3eca-d5f1-da4f- > e74181c5a862@redhat.com > https://edk2.groups.io/g/devel/message/47864 >=20 > 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.) >=20 > 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. >=20 > 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 >=20 > Thanks > Laszlo >=20 > 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) >=20 > 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 >=20 >=20 > -=3D-=3D-=3D-=3D-=3D-=3D > Groups.io Links: You receive all messages sent to this group. >=20 > View/Reply Online (#47924): https://edk2.groups.io/g/devel/message/47924 > Mute This Topic: https://groups.io/mt/34274934/1772286 > Group Owner: devel+owner@edk2.groups.io > Unsubscribe: https://edk2.groups.io/g/devel/unsub [jiewen.yao@intel.com] > -=3D-=3D-=3D-=3D-=3D-=3D