From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ml01.01.org (Postfix) with ESMTP id B1F971A1E20 for ; Fri, 29 Jul 2016 03:52:38 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP; 29 Jul 2016 03:52:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,439,1464678000"; d="scan'208";a="1004814856" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga001.jf.intel.com with ESMTP; 29 Jul 2016 03:52:38 -0700 Received: from fmsmsx122.amr.corp.intel.com (10.18.125.37) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 29 Jul 2016 03:52:37 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx122.amr.corp.intel.com (10.18.125.37) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 29 Jul 2016 03:52:37 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.147]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.116]) with mapi id 14.03.0248.002; Fri, 29 Jul 2016 18:52:35 +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//+CyACAAA/jAIAAjfhw Date: Fri, 29 Jul 2016 10:52:35 +0000 Message-ID: <542CF652F8836A4AB8DBFAAD40ED192A143C57FA@shsmsx102.ccr.corp.intel.com> References: <1469415184-8432-1-git-send-email-jeff.fan@intel.com> <542CF652F8836A4AB8DBFAAD40ED192A143C41A9@shsmsx102.ccr.corp.intel.com> <542CF652F8836A4AB8DBFAAD40ED192A143C5633@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjk4NGFjMTItOGU2Ni00YjVkLWI0ZDMtNjJiYzkzMTVhMDJlIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlpCdTRCSWF2VUZDSlwvM3BKNXhsQ1dYakJhQ2FNT1h0WTVqeVlsUlpoWDNVPSJ9 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 10:52:38 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Laszlo, Thanks again for your verification on OVMF.=20 Jeff -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Lasz= lo Ersek Sent: Friday, July 29, 2016 6:23 PM To: Fan, Jeff Cc: edk2-devel@ml01.01.org Subject: Re: [edk2] [Patch v3 00/40] MP Initialize Library On 07/29/16 11:25, Laszlo Ersek wrote: > On 07/29/16 10:57, Fan, Jeff wrote: >> Laszlo, >> >> I sent one evaluate patch for you by adding back GDT table load in CpuDx= e. Could you please help to verify if it could fix IA32 S3 issue? >=20 > Yes, I'll try to look into it shortly. I'll have to retest the other=20 > cases as well. Everything seems to work fine with your new patch added on top. Thanks Laszlo >> Another solution is to remove hardcode from PiSmmCpuDxeSmm driver.=20 >> 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=20 >> Of Laszlo 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, >>> >>> Many thanks for your verification.=20 >>> >>> Your dump information and analysis result are very useful. I guess the = issue happened at=20 >>> UefiCpuPkg\PiSmmCpuDxeSmm\Ia32\MpFuncs.nasm:80 a32 jmp dwo= rd 0x20:0x0 >>> >>> The Proteted mode CS in current GDT table is not 0x20. But the PiSmmCpu= DxeSmm 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 >>> >>> On 07/25/16 04:52, Jeff Fan wrote: >>>> We add MP Initialize Library defined in UefiCpuPkg/Include/Library/MpI= nitLib.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 mod= ules. >>>> >>>> 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 Qu= ark 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 sp= ec. >>>> 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 CheckAndUpdateAps= Status(). >>>> 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 #4= 0 to >>>> patch #39. >>>> 5. Update Patch #1, #3 - #8, #16 to >>>> a. Add Reviewed-by: Giri P Mudusuru=20 >>>> >>>> >>>> I fork the whole tree with the updated v3 patches at >>>> https://github.com/vanjeff/edk2/tree/MpInitLibV3 for review. >>> >>> I rebased your branch (originally at 09948b72fbb7) on top of current ma= ster (=3D 39dbc4d55347), and built it. It builds fine. >>> >>> Scenarios that I tested, and seem to work: >>> >>> * Q35, Ia32, with -D SMM_REQUIRE, 4 VCPUs, Fedora guest: >>> - normal boot path: pass >>> - S3 resume: FAIL (see details below) >>> >>> * i440fx, X64, without -D SMM_REQUIRE, 8 VCPUs, Fedora guest: >>> - normal boot path: pass >>> - S3 resume: pass >>> >>> I re-verified the fix for , which requires CpuMpPei to actually *work* on both boot path= s, and it works fine. >>> >>> * Q35, Ia32X64, with -D SMM_REQUIRE, 4 VCPUs, Fedora guest: >>> - normal boot path: pass >>> >>> On the normal boot path, I also verified that the MTRR setup was consis= tent across the VCPUs (otherwise Linux would have complained), plus the fix= for was working= fine too. I also checked that the UEFI variable services worked, bound to = the BSP, and then bound to the first AP as well. (Using the "taskset" Linux= command, with "efibootmgr", to list the variables.) I quickly checked that= Secure Boot was still recognized by the guest (Fedora) as enabled. >>> >>> - S3 resume: pass >>> >>> Repeated the BZ#86 check and the variable access checks from within the= resumed guest, all pass. >>> >>> * Q35, Ia32X64, with -D SMM_REQUIRE, 4 VCPUs, Windows 8.1 guest: >>> - normal boot path: pass >>> >>> On the normal boot path, I checked Secure Boot enablement with PowerShe= ll. >>> >>> - S3 resume: pass. >>> >>> Now, about the one failure case. QEMU logs the following: >>> >>>> 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= HLT=3D0 ES >>>> =3D9f00 0009f000 0000ffff 00009300 DPL=3D0 DS16 [-WA] CS =3D9f00 0009f= 000=20 >>>> 0000ffff 00009b00 DPL=3D0 CS16 [-RA] SS =3D9f00 0009f000 0000ffff >>>> 00009300 >>>> DPL=3D0 DS16 [-WA] DS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16= =20 >>>> [-WA] FS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16 [-WA] GS =3D0= 000 >>>> 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=20 >>>> <66> >>>> 67 ea 3b f0 09 00 20 00 66 b8 08 00 66 8e d8 66 8e c0 66 8e e0 66=20 >>>> 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= HLT=3D0 ES >>>> =3D9f00 0009f000 0000ffff 00009300 DPL=3D0 DS16 [-WA] CS =3D9f00 0009f= 000=20 >>>> 0000ffff 00009b00 DPL=3D0 CS16 [-RA] SS =3D9f00 0009f000 0000ffff >>>> 00009300 >>>> DPL=3D0 DS16 [-WA] DS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16= =20 >>>> [-WA] FS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16 [-WA] GS =3D0= 000 >>>> 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=20 >>>> <66> >>>> 67 ea 3b f0 09 00 20 00 66 b8 08 00 66 8e d8 66 8e c0 66 8e e0 66=20 >>>> 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= HLT=3D0 ES >>>> =3D9f00 0009f000 0000ffff 00009300 DPL=3D0 DS16 [-WA] CS =3D9f00 0009f= 000=20 >>>> 0000ffff 00009b00 DPL=3D0 CS16 [-RA] SS =3D9f00 0009f000 0000ffff >>>> 00009300 >>>> DPL=3D0 DS16 [-WA] DS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16= =20 >>>> [-WA] FS =3D0000 00000000 0000ffff 00009300 DPL=3D0 DS16 [-WA] GS =3D0= 000 >>>> 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=20 >>>> <66> >>>> 67 ea 3b f0 09 00 20 00 66 b8 08 00 66 8e d8 66 8e c0 66 8e e0 66=20 >>>> 8e >>>> e8 66 8e d0 89 d6 >>> >>> I didn't try to analyze this in depth, but from the hex-encoded instruc= tion stream, it looks like KVM dislikes the 0x66 prefix in front of a JMP i= nstruction (EA, if I recall correctly). Given that this is logged all at on= ce for three processors (out of 4 -- see the description of that test case = above), I believe one of the far jumps in the AP mode switching code is inc= orrect, on the S3 resume path, for Ia32 + SMM. >>> >>> Perhaps one of the "a32" or "o32" NASM prefixes should be tweaked. Simi= lar examples: , . >>> >>> Thanks! >>> Laszlo >>> >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >> >=20 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel