From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 6584C2034C09F for ; Fri, 20 Oct 2017 10:14:58 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4640F7E383; Fri, 20 Oct 2017 17:18:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4640F7E383 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-150.rdu2.redhat.com [10.10.120.150]) by smtp.corp.redhat.com (Postfix) with ESMTP id 30B365D75E; Fri, 20 Oct 2017 17:18:35 +0000 (UTC) To: Ard Biesheuvel Cc: "Gao, Liming" , "edk2-devel@lists.01.org" , Leif Lindholm References: <20171020112325.10814-1-ard.biesheuvel@linaro.org> <20171020130024.l73uww7cxsjnwbsv@bivouac.eciton.net> <51d0ef33-022f-7153-9acd-9bc4a26cdd59@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E16EABD@SHSMSX104.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <7c7676f9-39b4-39b6-24b7-7c83840df72a@redhat.com> Date: Fri, 20 Oct 2017 19:18:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 20 Oct 2017 17:18:37 +0000 (UTC) Subject: Re: [PATCH] ArmPlatformPkg/PrePeiCore: seed temporary stack before entering PEI core X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Oct 2017 17:14:58 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/20/17 18:52, Ard Biesheuvel wrote: > On 20 October 2017 at 17:51, Laszlo Ersek wrote: >> On 10/20/17 18:39, Ard Biesheuvel wrote: >>> On 20 October 2017 at 17:37, Gao, Liming wrote: >>>> Ard: >>>> This case is to share the same value between PeiCore and SecCore. I also think it will be better to define one fixed PCD in MdeModulePkg.dec for this value. Could you submit bugzillar to catch this issue first? >>>> >>> >>> Certainly! >> >> Would it be possible to define the PCD as UINT32, and task 64-bit SEC >> (and PEI_CORE) code to first construct the wider value manually (in a >> register or otherwise)? >> >> Just thinking out loud. >> > > Could you think the reasoning behind that out loud as well? Haha, good stab :) Sure. In your patch you have: +#define INIT_CAR_VALUE 0x5AA55AA55AA55AA5 for 64-bit, and +#define INIT_CAR_VALUE 0x5AA55AA5 for 32-bit. Both 64-bit assembly code in SEC, and 64-bit C-code in the PEI_CORE, can easily compose the large value from the small value, starting from FixedPcdGet32(). The alternatives are: - asking the 32-bit assembly code to truncate the 64-bit constant -- it won't compile, - defining *two* FixedAtBuild PCDs, one for 32-bit, another for 64-bit SEC -- an idea probably not universally liked. ... When I originally started writing my previous email, I even thought about introducing the PCD as UINT16 :) But then I realized, if any platform lacks *some* 32-bit mode when it sets up the stack in assembly, for C-language entry, then the platform won't be supported by edk2. Thanks Laszlo