From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.151.62.68; helo=nwk-aaemail-lapp03.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 73B0C211DB404 for ; Mon, 11 Mar 2019 09:30:20 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x2BGH7tM054572; Mon, 11 Mar 2019 09:30:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=DkqaVk+8+Pyosn+hu2vNk2JV+3yd44/p507W9z0ExzA=; b=eHazySp74WFfnW+GRtLpti0aMccjXkBzOJ2/9SYUGC9COlFEV3yB3d/NI71AxnapOobe 2heaklw+qVWn8xjl1D23qdKWSqeR4CVp7bFTD8FAfy06QQ4oBYavzsqsoqeSzMkLAGhG dwIvivaMDy0npreG9jatIsFYwFBnG4x0CvTdq6k0SPFeOo8n17eptVz0vgtEtp4egO+U vg6K5TsPJFKwsbT77UiKMYnsPihT5lWeVawcgSV874QgcRapCF8tAvCrcYOz4csNQig3 MqUSziMU6FtA8rgJ+NC7qp72YF7Ue2b1CmKxfRTGDJYUljmKDdlv1XxtDycP88HSGnWI +g== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2r4x129tfa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Mar 2019 09:30:19 -0700 MIME-version: 1.0 Received: from ma1-mmpp-sz10.apple.com (ma1-mmpp-sz10.apple.com [17.171.128.150]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPS id <0PO700DWWN6IL7E0@ma1-mtap-s02.corp.apple.com>; Mon, 11 Mar 2019 09:30:18 -0700 (PDT) Received: from process_milters-daemon.ma1-mmpp-sz10.apple.com by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) id <0PO700500MKEBW00@ma1-mmpp-sz10.apple.com>; Mon, 11 Mar 2019 09:30:18 -0700 (PDT) X-Va-A: X-Va-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-Va-E-CD: 4a87056218bf70415eb744810156915e X-Va-R-CD: e30b436eaaf3a02eee625f8c32ed8927 X-Va-CD: 0 X-Va-ID: 66dfb7dd-9dad-48b3-b3f8-4127d2edd2ab X-V-A: X-V-T-CD: 81ca60fce39c2560b6c4a7e5841f9b8f X-V-E-CD: 4a87056218bf70415eb744810156915e X-V-R-CD: e30b436eaaf3a02eee625f8c32ed8927 X-V-CD: 0 X-V-ID: fc43ad02-a1df-4202-90f5-cad585afde23 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-03-11_12:,, signatures=0 Received: from [17.234.186.230] (unknown [17.234.186.230]) by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20181024 64bit (built Oct 24 2018)) with ESMTPSA id <0PO700MTDN6AK030@ma1-mmpp-sz10.apple.com>; Mon, 11 Mar 2019 09:30:17 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: <74D8A39837DF1E4DA445A8C0B3885C503F561781@shsmsx102.ccr.corp.intel.com> Date: Mon, 11 Mar 2019 09:30:08 -0700 Cc: Laszlo Ersek , "edk2-devel@lists.01.org" , "Ni, Ray" , "Dong, Eric" Message-id: <74C068B9-84FC-4FD5-8591-A29D76A2A056@apple.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> To: "Yao, Jiewen" X-Mailer: Apple Mail (2.3445.6.18) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_12:, , signatures=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 16:30:20 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > 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? Jiewen, 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 loop favors the largest area of free memory. > As such all drivers are loaded to above 4GB? DXE Core is loaded low, and all the drivers loaded by DXE are in > 4GB memory. > Do you also allocate BIN to above 4GB? > No I just marked the above 4G memory as tested. Thanks, Andrew Fish > 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=1613 >> >> 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 before. 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 in 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 that >>>> 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 AP. 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 mode. 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 mode. >>> >>> 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 > 4GB >>>>>>> >>>>>>> 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 driver, >>>>>> 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 = AllocateRuntimePool (sizeof (GdtTemplate) + 8); >>>>>>> ASSERT (gdt != NULL); >>>>>>> gdt = ALIGN_POINTER (gdt, 8); >>>>>>> >>>>>>> // >>>>>>> // Initialize all GDT entries >>>>>>> // >>>>>>> CopyMem (gdt, &GdtTemplate, sizeof (GdtTemplate)); >>>>>>> >>>>>>> // >>>>>>> // Write GDT register >>>>>>> // >>>>>>> gdtPtr.Base = (UINT32)(UINTN)(VOID*) gdt; >>>>>>> gdtPtr.Limit = (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