From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ml01.01.org (Postfix) with ESMTP id 94B311A1DF5 for ; Fri, 29 Jul 2016 01:57:18 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 29 Jul 2016 01:57:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,438,1464678000"; d="scan'208";a="1016083582" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga001.fm.intel.com with ESMTP; 29 Jul 2016 01:57:19 -0700 Received: from fmsmsx121.amr.corp.intel.com (10.18.125.36) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 29 Jul 2016 01:57:17 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx121.amr.corp.intel.com (10.18.125.36) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 29 Jul 2016 01:57:17 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.147]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.8]) with mapi id 14.03.0248.002; Fri, 29 Jul 2016 16:57:15 +0800 From: "Fan, Jeff" To: Laszlo Ersek CC: "edk2-devel@ml01.01.org" Thread-Topic: [edk2] [Patch v3 00/40] MP Initialize Library Thread-Index: AQHR5h/pRgPkX5Xhb0++xXLZ1Z6XN6AtVEAAgACL+kD//5S0AIABrFmQ Date: Fri, 29 Jul 2016 08:57:14 +0000 Message-ID: <542CF652F8836A4AB8DBFAAD40ED192A143C5633@shsmsx102.ccr.corp.intel.com> References: <1469415184-8432-1-git-send-email-jeff.fan@intel.com> <542CF652F8836A4AB8DBFAAD40ED192A143C41A9@shsmsx102.ccr.corp.intel.com> In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTViNTE4MTYtMDE1YS00YmZmLTgyZTctYTAwYjBkM2EzZGQ2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlhZQ21DbzV2M0JXTWZUU3k5RGFHQkhyOXJPRHQ1Mk1CWDJZcUN1Q1FBVkU9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: [Patch v3 00/40] MP Initialize Library X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2016 08:57:18 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Laszlo, I sent one evaluate patch for you by adding back GDT table load in CpuDxe. = Could you please help to verify if it could fix IA32 S3 issue? Another solution is to remove hardcode from PiSmmCpuDxeSmm driver. But I do= not prefer to do it this time. :-) Thanks! Jeff -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Lasz= lo Ersek Sent: Thursday, July 28, 2016 11:21 PM To: Fan, Jeff Cc: edk2-devel@ml01.01.org Subject: Re: [edk2] [Patch v3 00/40] MP Initialize Library On 07/28/16 15:55, Fan, Jeff wrote: > Laszlo, >=20 > Many thanks for your verification.=20 >=20 > Your dump information and analysis result are very useful. I guess the is= sue happened at=20 > UefiCpuPkg\PiSmmCpuDxeSmm\Ia32\MpFuncs.nasm:80 a32 jmp dword= 0x20:0x0 >=20 > The Proteted mode CS in current GDT table is not 0x20. But the PiSmmCpuDx= eSmm hardcode it to 0x20. Ah, good point; I recall: commit 0d4c1db81aab86963536deb8253f35546c4398ea Author: Michael Kinney Date: Fri Oct 30 17:32:27 2015 +0000 UefiCpuPkg: CpuDxe: Update GDT to be consistent with DxeIplPeim as another related patch. > I will try it fix it tomorrow and feedback to you.=20 Thank you, I'll attempt to test it soon after. Cheers Laszlo > -----Original Message----- > From: Laszlo Ersek [mailto:lersek@redhat.com] > Sent: Thursday, July 28, 2016 9:24 PM > To: Fan, Jeff; edk2-devel@ml01.01.org > Subject: Re: [edk2] [Patch v3 00/40] MP Initialize Library >=20 > On 07/25/16 04:52, Jeff Fan wrote: >> We add MP Initialize Library defined in UefiCpuPkg/Include/Library/MpIni= tLib.h. >> It will provide basic functionalities of MP services and could be=20 >> consumed by CPU MP PEI and CPU MP DXE to produce CPU MP PPI and CPU=20 >> MP Protocol. Then most of code could be shared between PEI and DXE modul= es. >> >> PeiMpInitLib and DxeMpInitLib are added to make the CpuMpPei and=20 >> CpuDxe more simply. >> >> I also updated the Ovmf Platform and Quark platform to consume MP=20 >> Initialize library. I have tested Ovmf platform and have not tested Quar= k yet. >> >> v3: >> 1. Update Patch #2, #4 - #8, #28, #33, #36, #38 per Giri's comments to >> a. Update SDM date to June, 2016 >> b. Mention BCD format in CPU_MICROCODE_DATE >> c. Rename ProcessorChecksum to Checksum to match SDM. >> d. Add whitespace after MpInitLibInitialize >> e. Rename MpInitLibSwitchBsp to MpInitLibSwitchBSP to match PI spec= . >> f. Rename NumApsExecutingLoction to NumApsExecutingLocation >> g. Add whitespace after ; in .nasm file >> h. Rename *RellocateAp* to *RelocateAp* >> 2. Update Patch #16, #17, #29-#32 to >> a. Use CamelCase for mStopCheckAllApsStatus and CheckAndUpdateApsSt= atus(). >> 3. Update Patch #36 and #39 to >> a. Add PeiMpInitLib instance in UefiCpuPkg.dsc >> b. Add DxeMpInitLib instance in UefiCpuPkg.dsc >> 4. Update Patch #39 and #40 to=20 >> a. move the code of consuming MP Initialize library from patch #40 = to >> patch #39. >> 5. Update Patch #1, #3 - #8, #16 to >> a. Add Reviewed-by: Giri P Mudusuru >> >> I fork the whole tree with the updated v3 patches at >> https://github.com/vanjeff/edk2/tree/MpInitLibV3 for review. >=20 > I rebased your branch (originally at 09948b72fbb7) on top of current mast= er (=3D 39dbc4d55347), and built it. It builds fine. >=20 > Scenarios that I tested, and seem to work: >=20 > * Q35, Ia32, with -D SMM_REQUIRE, 4 VCPUs, Fedora guest: > - normal boot path: pass > - S3 resume: FAIL (see details below) >=20 > * i440fx, X64, without -D SMM_REQUIRE, 8 VCPUs, Fedora guest: > - normal boot path: pass > - S3 resume: pass >=20 > I re-verified the fix for , which requires CpuMpPei to actually *work* on both boot paths,= and it works fine. >=20 > * Q35, Ia32X64, with -D SMM_REQUIRE, 4 VCPUs, Fedora guest: > - normal boot path: pass >=20 > On the normal boot path, I also verified that the MTRR setup was consiste= nt across the VCPUs (otherwise Linux would have complained), plus the fix f= or was working f= ine too. I also checked that the UEFI variable services worked, bound to th= e BSP, and then bound to the first AP as well. (Using the "taskset" Linux c= ommand, with "efibootmgr", to list the variables.) I quickly checked that S= ecure Boot was still recognized by the guest (Fedora) as enabled. >=20 > - S3 resume: pass >=20 > Repeated the BZ#86 check and the variable access checks from within the r= esumed guest, all pass. >=20 > * Q35, Ia32X64, with -D SMM_REQUIRE, 4 VCPUs, Windows 8.1 guest: > - normal boot path: pass >=20 > On the normal boot path, I checked Secure Boot enablement with PowerShell= . >=20 > - S3 resume: pass. >=20 > Now, about the one failure case. QEMU logs the following: >=20 >> KVM internal error. Suberror: 3 >> KVM internal error. Suberror: 3 >> KVM internal error. Suberror: 3 >> extra data[0]: 80000b0d >> extra data[0]: 80000b0d >> extra data[1]: 31 >> extra data[1]: 31 >> extra data[0]: 80000b0d >> extra data[1]: 31 >> >> EAX=3D60000011 EBX=3D00000000 ECX=3D00000000 EDX=3D0009f000 >> ESI=3D000000b5 EDI=3D00000000 EBP=3D00000000 ESP=3D00000000 >> EIP=3D00000032 EFL=3D00010006 [-----P-] CPL=3D0 II=3D0 A20=3D1 SMM=3D0 H= LT=3D0 ES >> =3D9f00 0009f000 0000ffff 00009300 DPL=3D0 DS16 [-WA] CS =3D9f00 0009f00= 0=20 >> 0000ffff 00009b00 DPL=3D0 CS16 [-RA] SS =3D9f00 0009f000 0000ffff=20 >> 00009300 >> DPL=3D0 DS16 [-WA] DS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16 [-= WA]=20 >> FS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16 [-WA] GS =3D0000=20 >> 00000000 0000ffff 00009300 DPL=3D0 DS16 [-WA] >> LDT=3D0000 00000000 0000ffff 00008200 DPL=3D0 LDT TR =3D0000 00000000=20 >> 0000ffff 00008b00 DPL=3D0 TSS32-busy >> GDT=3D 7f2d8000 00000017 >> IDT=3D 7f2d8018 000007ff >> CR0=3D60000011 CR2=3D00000000 CR3=3D00000000 CR4=3D00000000 >> DR0=3D00000000 DR1=3D00000000 DR2=3D00000000 DR3=3D00000000 >> DR6=3Dffff0ff0 DR7=3D00000400 >> EFER=3D0000000000000000 >> Code=3D00 2e 66 0f 01 1c 31 c0 8e d8 0f 20 c0 66 83 c8 01 0f 22 c0 <66> >> 67 ea 3b f0 09 00 20 00 66 b8 08 00 66 8e d8 66 8e c0 66 8e e0 66 8e >> e8 66 8e d0 89 d6 >> >> EAX=3D60000011 EBX=3D00000000 ECX=3D00000000 EDX=3D0009f000 >> ESI=3D000000b5 EDI=3D00000000 EBP=3D00000000 ESP=3D00000000 >> EIP=3D00000032 EFL=3D00010006 [-----P-] CPL=3D0 II=3D0 A20=3D1 SMM=3D0 H= LT=3D0 ES >> =3D9f00 0009f000 0000ffff 00009300 DPL=3D0 DS16 [-WA] CS =3D9f00 0009f00= 0=20 >> 0000ffff 00009b00 DPL=3D0 CS16 [-RA] SS =3D9f00 0009f000 0000ffff=20 >> 00009300 >> DPL=3D0 DS16 [-WA] DS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16 [-= WA]=20 >> FS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16 [-WA] GS =3D0000=20 >> 00000000 0000ffff 00009300 DPL=3D0 DS16 [-WA] >> LDT=3D0000 00000000 0000ffff 00008200 DPL=3D0 LDT TR =3D0000 00000000=20 >> 0000ffff 00008b00 DPL=3D0 TSS32-busy >> GDT=3D 7f2d8000 00000017 >> IDT=3D 7f2d8018 000007ff >> CR0=3D60000011 CR2=3D00000000 CR3=3D00000000 CR4=3D00000000 >> DR0=3D00000000 DR1=3D00000000 DR2=3D00000000 DR3=3D00000000 >> DR6=3Dffff0ff0 DR7=3D00000400 >> EFER=3D0000000000000000 >> Code=3D00 2e 66 0f 01 1c 31 c0 8e d8 0f 20 c0 66 83 c8 01 0f 22 c0 <66> >> 67 ea 3b f0 09 00 20 00 66 b8 08 00 66 8e d8 66 8e c0 66 8e e0 66 8e >> e8 66 8e d0 89 d6 >> >> EAX=3D60000011 EBX=3D00000000 ECX=3D00000000 EDX=3D0009f000 >> ESI=3D000000b5 EDI=3D00000000 EBP=3D00000000 ESP=3D00000000 >> EIP=3D00000032 EFL=3D00010006 [-----P-] CPL=3D0 II=3D0 A20=3D1 SMM=3D0 H= LT=3D0 ES >> =3D9f00 0009f000 0000ffff 00009300 DPL=3D0 DS16 [-WA] CS =3D9f00 0009f00= 0=20 >> 0000ffff 00009b00 DPL=3D0 CS16 [-RA] SS =3D9f00 0009f000 0000ffff=20 >> 00009300 >> DPL=3D0 DS16 [-WA] DS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16 [-= WA]=20 >> FS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16 [-WA] GS =3D0000=20 >> 00000000 0000ffff 00009300 DPL=3D0 DS16 [-WA] >> LDT=3D0000 00000000 0000ffff 00008200 DPL=3D0 LDT TR =3D0000 00000000=20 >> 0000ffff 00008b00 DPL=3D0 TSS32-busy >> GDT=3D 7f2d8000 00000017 >> IDT=3D 7f2d8018 000007ff >> CR0=3D60000011 CR2=3D00000000 CR3=3D00000000 CR4=3D00000000 >> DR0=3D00000000 DR1=3D00000000 DR2=3D00000000 DR3=3D00000000 >> DR6=3Dffff0ff0 DR7=3D00000400 >> EFER=3D0000000000000000 >> Code=3D00 2e 66 0f 01 1c 31 c0 8e d8 0f 20 c0 66 83 c8 01 0f 22 c0 <66> >> 67 ea 3b f0 09 00 20 00 66 b8 08 00 66 8e d8 66 8e c0 66 8e e0 66 8e >> e8 66 8e d0 89 d6 >=20 > I didn't try to analyze this in depth, but from the hex-encoded instructi= on stream, it looks like KVM dislikes the 0x66 prefix in front of a JMP ins= truction (EA, if I recall correctly). Given that this is logged all at once= for three processors (out of 4 -- see the description of that test case ab= ove), I believe one of the far jumps in the AP mode switching code is incor= rect, on the S3 resume path, for Ia32 + SMM. >=20 > Perhaps one of the "a32" or "o32" NASM prefixes should be tweaked. Simila= r examples: , = . >=20 > Thanks! > Laszlo >=20 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel