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.43, mailfrom: jiewen.yao@intel.com) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by groups.io with SMTP; Mon, 30 Sep 2019 07:23:00 -0700 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Sep 2019 07:22:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,567,1559545200"; d="scan'208";a="202899911" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga002.jf.intel.com with ESMTP; 30 Sep 2019 07:22:59 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 30 Sep 2019 07:22:58 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 30 Sep 2019 07:22:58 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.176]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.165]) with mapi id 14.03.0439.000; Mon, 30 Sep 2019 22:22:55 +0800 From: "Yao, Jiewen" To: "devel@edk2.groups.io" , "imammedo@redhat.com" , Laszlo Ersek CC: "qemu-devel@nongnu.org" , "Chen, Yingwen" , "phillip.goerl@oracle.com" , "alex.williamson@redhat.com" , "Nakajima, Jun" , "Kinney, Michael D" , "pbonzini@redhat.com" , "boris.ostrovsky@oracle.com" , "rfc@edk2.groups.io" , "joao.m.martins@oracle.com" , Brijesh Singh Subject: Re: [edk2-devel] [Qemu-devel] [PATCH 1/2] q35: implement 128K SMRAM at default SMBASE address Thread-Topic: [edk2-devel] [Qemu-devel] [PATCH 1/2] q35: implement 128K SMRAM at default SMBASE address Thread-Index: AQHVcsoJd8i/V0oK70G7GW0woCa/SKdDny4AgAAMooCAAJ75IA== Date: Mon, 30 Sep 2019 14:22:54 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F7DFDB3@shsmsx102.ccr.corp.intel.com> References: <20190917130708.10281-1-imammedo@redhat.com> <20190917130708.10281-2-imammedo@redhat.com> <561f4440-7c06-10d7-80ce-bbfa810fec59@redhat.com> <20190920102855.3fe2b689@redhat.com> <20190924131936.7dec5e6c@redhat.com> <20190930143659.6de53f70@redhat.com> In-Reply-To: <20190930143659.6de53f70@redhat.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMzVhMjQ5YTktZTdlNC00ODA5LWI4N2MtYzM0NjViYmYxN2RjIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiKzlvaUd2ek1DbDFIWGVOSTZYSWZ2c1p1MU5JTkxvWjczcHNDYWlsYjJcLzhcL3hLdkxMNko1SHZVRjhudkJJdFhWIn0= 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 below > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Igor > Mammedov > Sent: Monday, September 30, 2019 8:37 PM > To: Laszlo Ersek > Cc: devel@edk2.groups.io; qemu-devel@nongnu.org; Chen, Yingwen > ; phillip.goerl@oracle.com; > alex.williamson@redhat.com; Yao, Jiewen ; Nakajima= , > Jun ; Kinney, Michael D > ; pbonzini@redhat.com; > boris.ostrovsky@oracle.com; rfc@edk2.groups.io; joao.m.martins@oracle.co= m; > Brijesh Singh > Subject: Re: [edk2-devel] [Qemu-devel] [PATCH 1/2] q35: implement 128K > SMRAM at default SMBASE address >=20 > On Mon, 30 Sep 2019 13:51:46 +0200 > "Laszlo Ersek" wrote: >=20 > > Hi Igor, > > > > On 09/24/19 13:19, Igor Mammedov wrote: > > > On Mon, 23 Sep 2019 20:35:02 +0200 > > > "Laszlo Ersek" wrote: > > > > >> I've got good results. For this (1/2) QEMU patch: > > >> > > >> Tested-by: Laszlo Ersek > > >> > > >> I tested the following scenarios. In every case, I verified the OVM= F > > >> log, and also the "info mtree" monitor command's result (i.e. wheth= er > > >> "smbase-blackhole" / "smbase-window" were disabled or enabled). > > >> Mostly, I diffed these text files between the test scenarios (looki= ng > > >> for desired / undesired differences). In the Linux guests, I checke= d > > >> / compared the dmesg too (wrt. the UEFI memmap). > > >> > > >> - unpatched OVMF (regression test), Fedora guest, normal boot and S= 3 > > >> > > >> - patched OVMF, but feature disabled with "-global > > >> mch.smbase-smram=3Doff" (another regression test), Fedora guest, > > >> normal boot and S3 > > >> > > >> - patched OVMF, feature enabled, Fedora and various Windows guests > > >> (win7, win8, win10 families, client/server), normal boot and S3 > > >> > > >> - a subset of the above guests, with S3 disabled (-global > > >> ICH9-LPC.disable_s3=3D1), and obviously S3 resume not tested > > >> > > >> SEV: used 5.2-ish Linux guest, with S3 disabled (no support under S= EV > > >> for that now): > > >> > > >> - unpatched OVMF (regression test), normal boot > > >> > > >> - patched OVMF but feature disabled on the QEMU cmdline (another > > >> regression test), normal boot > > >> > > >> - patched OVMF, feature enabled, normal boot. > > >> > > >> I plan to post the OVMF patches tomorrow, for discussion. > > >> > > >> (It's likely too early to push these QEMU / edk2 patches right now = -- > > >> we don't know yet if this path will take us to the destination. For > > >> now, it certainly looks great.) > > > > > > Laszlo, thanks for trying it out. > > > It's nice to hear that approach is somewhat usable. > > > Hopefully we won't have to invent 'paused' cpu mode. > > > > > > Pls CC me on your patches > > > (not that I qualify for reviewing, > > > but may be I could learn a thing or two from it) > > > > Considering the plan at [1], the two patch sets [2] [3] should cover > > step (01); at least as proof of concept. > > > > [1] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > > http://mid.mail-archive.com/20190830164802.1b17ff26@redhat.com > > > > [2] The current thread: > > [Qemu-devel] [PATCH 0/2] q35: mch: allow to lock down 128K RAM at > default SMBASE address > > http://mid.mail-archive.com/20190917130708.10281-1- > imammedo@redhat.com > > > > [3] [edk2-devel] [PATCH wave 1 00/10] support QEMU's "SMRAM at default > SMBASE" feature > > http://mid.mail-archive.com/20190924113505.27272-1-lersek@redhat.c= om > > > > (I'll have to figure out what SMI handler to put in place there, but I= 'd > > like to experiment with that once we can cause a new CPU to start > > executing code there, in SMM.) > > > > So what's next? > > > > To me it looks like we need to figure out how QEMU can make the OS cal= l > > into SMM (in the GPE cpu hotplug handler), passing in parameters and > > such. This would be step (03). > > > > Do you agree? > > > > If so, I'll ask Jiewen about such OS->SMM calls separately, because I > > seem to remember that there used to be an "SMM communcation table" of > > sorts, for flexible OS->SMM calls. However, it appears to be deprecate= d > > lately. > we can try to resurrect and put over it some kind of protocol > to describe which CPUs to where hotplugged. >=20 > or we could put a parameter into SMI status register (IO port 0xb3) > and the trigger SMI from GPE handler to tell SMI handler that cpu > hotplug happened and then use QEMU's cpu hotplug interface > to enumerate hotplugged CPUs for SMI handler. >=20 > The later is probably simpler as we won't need to reinvent the wheel > (just reuse the interface that's already in use by GPE handler). [Jiewen] The PI specification Volume 4 - SMM defines EFI_MM_COMMUNICATION_= PROTOCOL.Communicate() - It can be used to communicate between OS and SMM h= andler. But it requires the runtime protocol call. I am not sure how OS loa= der passes this information to OS kernel. As such, I think using ACPI SCI/GPE -> software SMI handler is an easier w= ay to achieve this. I also recommend this way. For parameter passing, we can use 1) Port B2 (1 byte), 2) Port B3 (1 byte)= , 3) chipset scratch register (4 bytes or 8 bytes, based upon scratch regis= ter size), 4) ACPI NVS OPREGION, if the data structure is complicated. > > Hmmm.... Yes, UEFI 2.8 has "Appendix O - UEFI ACPI Data Table", and it > > writes (after defining the table format): > > > > The first use of this UEFI ACPI table format is the SMM > > Communication ACPI Table. This table describes a special software > > SMI that can be used to initiate inter-mode communication in the O= S > > present environment by non-firmware agents with SMM code. > > > > Note: The use of the SMM Communication ACPI table is deprecated in > > UEFI spec. 2.7. This is due to the lack of a use case for > > inter-mode communication by non-firmware agents with SMM cod= e > > and support for initiating this form of communication in > > common OSes. > > > > The changelog at the front of the UEFI spec also references the > > Mantis#1691 spec ticket, "Remove/Deprecate SMM Communication ACPI > Table" > > (addressed in UEFI 2.6B). > > > > (I think that must have been a security ticket, because, while I > > generally have access to Mantis tickets, > > gives me "Access > > Denied" :/ ) > > > > Thanks, > > Laszlo > > > > > > >=20 >=20 >=20