From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.126; helo=mga18.intel.com; envelope-from=jiewen.yao@intel.com; receiver=edk2-devel@lists.01.org Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A74BD211D56B3 for ; Mon, 11 Mar 2019 14:06:50 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2019 14:06:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,468,1544515200"; d="scan'208";a="151378731" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga004.fm.intel.com with ESMTP; 11 Mar 2019 14:06:02 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Mar 2019 14:05:00 -0700 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.163]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.134]) with mapi id 14.03.0415.000; Tue, 12 Mar 2019 05:04:20 +0800 From: "Yao, Jiewen" To: "afish@apple.com" CC: Laszlo Ersek , "edk2-devel@lists.01.org" , "Ni, Ray" , "Dong, Eric" , "Yao, Jiewen" Thread-Topic: [edk2] UefiCpuPkg CpuDxe GDT init question? Thread-Index: AQHU1TaA3YHFoTLTrEqWLOi5Mqa6G6YA2UgAgADqghD//40oAIAAyd+AgAP7V4CAAIbNQP//geMAgADSc6A= Date: Mon, 11 Mar 2019 21:04:18 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503F562097@shsmsx102.ccr.corp.intel.com> References: <96DCE1C9-B02B-4520-A483-F72BBAAAB3B8@apple.com> <480fe32f-032e-0bf8-a561-c41a16213b82@redhat.com> <74D8A39837DF1E4DA445A8C0B3885C503F55C19B@shsmsx102.ccr.corp.intel.com> <656e8ae9-7163-6993-592e-75fa6b1c768d@redhat.com> <026A6544-28E8-427A-8C69-EE58B5C5639E@apple.com> <2477C2FC-463E-46C2-AA99-522350B3A8E9@apple.com> <74D8A39837DF1E4DA445A8C0B3885C503F561781@shsmsx102.ccr.corp.intel.com> <74C068B9-84FC-4FD5-8591-A29D76A2A056@apple.com> In-Reply-To: <74C068B9-84FC-4FD5-8591-A29D76A2A056@apple.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTlmOGQ4OGQtNDg4My00Mjk1LTk1OWMtNGMzZTcwYmM1YzM3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiVXBqdDZpM2ljXC9iWWEwTXJIdUsyakRicU5kdTJRUko1NXJJOEF5NTlsQnZnRnJBN2xnWTNJeFFZNWYzZVFyOXIifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: UefiCpuPkg CpuDxe GDT init question? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:06:50 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Understood. Cool. Thanks for the info. If you have some clue on the SMM, please let us know. Thank you Yao Jiewen > -----Original Message----- > From: afish@apple.com [mailto:afish@apple.com] > Sent: Tuesday, March 12, 2019 12:30 AM > To: Yao, Jiewen > Cc: Laszlo Ersek ; edk2-devel@lists.01.org; Ni, Ray > ; Dong, Eric > Subject: Re: [edk2] UefiCpuPkg CpuDxe GDT init question? >=20 >=20 >=20 > > On Mar 11, 2019, at 9:04 AM, Yao, Jiewen wrote: > > > > Thanks Andrew. > > + More CPU people in our team. > > > > Do you want to post your patch there for reference? :-) > > > > BTW: Would you please share how to trigger such case at your side? > > Did you report above 4GB memory to be tested? >=20 > Jiewen, >=20 > I'm working on a chipset that is not open source and I or'ed in > EFI_RESOURCE_ATTRIBUTE_TESTED to the above 4GB allocation in > BuildResourceDescriptorHob(). The DXE Core then picked this area for the > heap, as I seem to remember the 1st loop favors the PHIT, and the 2nd loo= p > favors the largest area of free memory. >=20 > > As such all drivers are loaded to above 4GB? >=20 > DXE Core is loaded low, and all the drivers loaded by DXE are in > 4GB > memory. >=20 > > Do you also allocate BIN to above 4GB? > > >=20 > No I just marked the above 4G memory as tested. >=20 > Thanks, >=20 > Andrew Fish >=20 > > Thank you > > Yao Jiewen > > > > > > > >> -----Original Message----- > >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > >> Andrew Fish via edk2-devel > >> Sent: Monday, March 11, 2019 11:59 PM > >> To: Yao, Jiewen > >> Cc: edk2-devel ; Laszlo Ersek > > >> Subject: Re: [edk2] UefiCpuPkg CpuDxe GDT init question? > >> > >> Jiewen, > >> > >> These three fixes got me past the CpuDxe driver: > >> https://bugzilla.tianocore.org/show_bug.cgi?id=3D1613 > >> > >> Now I getting page faults loading SMM.... > >> > >> Thanks, > >> > >> Andrew Fish > >> > >>> On Mar 8, 2019, at 7:10 PM, Andrew Fish wrote: > >>> > >>> > >>> > >>>> On Mar 8, 2019, at 7:08 AM, Laszlo Ersek >> > wrote: > >>>> > >>>> On 03/08/19 15:13, Yao, Jiewen wrote: > >>>>> I guess the historic reason is that AP and BSP share same GDT befor= e. > As > >> such, the GDT need to be below 4G, to let AP switch from real mode to > >> protected mode. > >>>>> We don't get issue, because Runtime memory is in BIN, and most > >> platform allocates BIN under 4G. > >>>>> > >>>>> Some thought: > >>>>> 1) I am think we not sure if AP is using same GDT as BSP today. If = yes, > we > >> need GDT under 4G, by using MaxAddress. If no, there should be no > >> restriction for BSP GDT. The (UINT32) case should be removed for BSP. > But > >> we still AP GDT below 4G, to support wake from INIT-SIPI-SIPI. > >>> > >>> Jiewen, > >>> > >>> It looks like there are several places that assume memory is < 4 GB i= n the > >> CpuDxe driver. > >>> > >>> I noticed SetCodeSelector () is using a far jump to change the CS at = that > is > >> limited < 4 GB. I had to hack around it via: > >>> popq %rax > >>> pushq %rcx > >>> pushq %rax > >>> lretq > >>> > >>> There is some other crash later on. > >>> > >>> > >>>>> 2) I am not sure why we need runtime memory. Do we need touch > GDT > >> at UEFI runtime? > >>>> > >>>> I could be confusing things *very badly*, but I vaguely remember tha= t > >>>> APs could be woken up spuriously later, and they must be able to > execute > >>>> code "enough" to go back to sleep. > >>>> > >>>> The following commits look relevant: > >>>> > >>>> - 7615702169b8 ("UefiCpuPkg/MpInitLib: Add AsmRelocateApLoop() > >> assembly > >>>> code", 2016-08-17) > >>>> > >>>> - 4d3314f69488 ("UefiCpuPkg/MpInitLib: Place APs in safe loop before > >>>> hand-off to OS", 2016-08-17) > >>>> > >>>> - bf2786dc7900 ("UefiCpuPkg/DxeMpLib: Allocate new safe stack < > 4GB", > >>>> 2016-11-28) > >>>> > >>> > >>> If I'm remembering correctly there are optional idle states for the A= P. I > >> think the real mode hlt loop might have used too much power on an UP > OS. > >>> > >>> It is also not clear to me that we don't need the GDT when in real mo= de. > In > >> big-real mode you go to protected mode set the GDT and then it can get > >> used for big-real so it seems like the GDT is in play even in real mo= de. > >>> > >>> Thanks, > >>> > >>> Andrew Fish > >>> > >>> > >>>> Laszlo > >>>> > >>>>> > >>>>> > >>>>> > >>>>> Thank you > >>>>> Yao Jiewen > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org > >> ] On Behalf Of > >>>>>> Laszlo Ersek > >>>>>> Sent: Friday, March 8, 2019 12:00 AM > >>>>>> To: Andrew Fish >; > >> edk2-devel > > >>>>>> Subject: Re: [edk2] UefiCpuPkg CpuDxe GDT init question? > >>>>>> > >>>>>> Hi Andrew, > >>>>>> > >>>>>> On 03/07/19 23:37, Andrew Fish via edk2-devel wrote: > >>>>>>> I'm trying to understand why gdtPtr.Base is casting to (UINT32)? > >>>>>>> 1) gdtPtr.Base is a a UINTN > >>>>>>> 2) It is legal for AllocateRuntimePool() to return an address > 4= GB > >>>>>>> > >>>>>>> It seems like the code should just cast to (UINTN)? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >> > https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/CpuDxe/CpuG > >> > >> G> > >>>>>> dt.c#L151 > >>>>>> > >>>>>> I think you are right. > >>>>>> > >>>>>> I'm missing the background on this too. I tried to see if any > >>>>>> justification was given in a git commit message, but according to = "git > >>>>>> blame", this code dates back to the original addition of the drive= r, > >>>>>> namely commit a47463f28382 ("Add CPU DXE driver for IA32 & X64 > >>>>>> processor > >>>>>> architectures.", 2009-05-27). The commit message is unhelpful (for > >> 3119 > >>>>>> lines added). > >>>>>> > >>>>>> Thanks > >>>>>> Laszlo > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> VOID > >>>>>>> InitGlobalDescriptorTable ( > >>>>>>> VOID > >>>>>>> ) > >>>>>>> { > >>>>>>> GDT_ENTRIES *gdt; > >>>>>>> IA32_DESCRIPTOR gdtPtr; > >>>>>>> > >>>>>>> // > >>>>>>> // Allocate Runtime Data for the GDT > >>>>>>> // > >>>>>>> gdt =3D AllocateRuntimePool (sizeof (GdtTemplate) + 8); > >>>>>>> ASSERT (gdt !=3D NULL); > >>>>>>> gdt =3D ALIGN_POINTER (gdt, 8); > >>>>>>> > >>>>>>> // > >>>>>>> // Initialize all GDT entries > >>>>>>> // > >>>>>>> CopyMem (gdt, &GdtTemplate, sizeof (GdtTemplate)); > >>>>>>> > >>>>>>> // > >>>>>>> // Write GDT register > >>>>>>> // > >>>>>>> gdtPtr.Base =3D (UINT32)(UINTN)(VOID*) gdt; > >>>>>>> gdtPtr.Limit =3D (UINT16) (sizeof (GdtTemplate) - 1); > >>>>>>> AsmWriteGdtr (&gdtPtr); > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Andrew Fish > >>>>>>> _______________________________________________ > >>>>>>> edk2-devel mailing list > >>>>>>> edk2-devel@lists.01.org > >>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> edk2-devel mailing list > >>>>>> edk2-devel@lists.01.org > >>>>>> https://lists.01.org/mailman/listinfo/edk2-devel > >> > >> _______________________________________________ > >> edk2-devel mailing list > >> edk2-devel@lists.01.org > >> https://lists.01.org/mailman/listinfo/edk2-devel