From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::236; helo=mail-it0-x236.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id DE5A120347163 for ; Fri, 20 Oct 2017 03:19:21 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id f187so13457758itb.1 for ; Fri, 20 Oct 2017 03:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/H9h4YB23hzudb50d/UbxvPXSuZz9T/J+0pdVSdHSSM=; b=KCJRRBon/nhpCt3Vyt3vvOg2QlvhbS/Ml2ve0ZKXqNteohH/El4uzbOnDN7Zv5T1Gv xno+np+1e8uxgvlPkujGeMHU94dBh3Dhl35E/OL2O7CNCHjwUQEx5qIWa2ceKetTBM4f 5pfqOCzkAxILni9J1z31RnIdFBnY0sycSTApU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/H9h4YB23hzudb50d/UbxvPXSuZz9T/J+0pdVSdHSSM=; b=qNd0iA0jUS2+GNerIe34pTuwKSqoEGQVnJQRaV5VDbBp4Vhz2n4mMk6SDiF0LYCP25 neD6/oXgjeS+bsoxGBkrAIrU2FSIiWjg0sVos/ijBUQ687prjg5qUfG/O1qhS04JVhae JbylgzkUuQglDLcotA1Sf5xA7kzFXKE6EanG1q+2O5ZkQ3U44b4HKE0Gkw8VpIo6OIZT jQIpAOidS12WNjl9FP3YV39FmMGIt8NwUTDQZGj+wT3Q9Dzjx6Cfrvc04uErvNKOnS49 HrHg+PUYHao8Q2xZCTcgXsBDpzFqhZRhrgMHYN4yP5WVUvKp4byzbC8dxEQvVgxg8Ya5 QSgA== X-Gm-Message-State: AMCzsaXZzjvFMgipjdJhUV3PKGMaUWnTVtFfiTp49WxGoONMxSriXpEx cokYU01+nbbj8TBvZ6uFHR4/VJrEnEHloq0YnOvvOw== X-Google-Smtp-Source: ABhQp+RQ7lA8g2nz1waqYPiH2KSH5TnqYYONEy3FaAheXEaZGv0YsIRdstLjRkNuSHDe1QdB0nO01kRdsrTBYjvLTKw= X-Received: by 10.36.31.212 with SMTP id d203mr1719964itd.48.1508494980280; Fri, 20 Oct 2017 03:23:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.131.167 with HTTP; Fri, 20 Oct 2017 03:22:59 -0700 (PDT) In-Reply-To: References: From: Ard Biesheuvel Date: Fri, 20 Oct 2017 11:22:59 +0100 Message-ID: To: Laszlo Ersek Cc: "Gao, Liming" , Star Zeng , "Jordan Justen (Intel address)" , edk2-devel-01 Subject: Re: dynamic PCD impact on temporary PEI memory 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 10:19:22 -0000 Content-Type: text/plain; charset="UTF-8" On 20 October 2017 at 10:43, Laszlo Ersek wrote: > On 10/20/17 09:57, Ard Biesheuvel wrote: >> On 19 October 2017 at 23:08, Laszlo Ersek wrote: > >>> * Symptom #1: >>> >>> I built OVMF for IA32, IA32X64 and X64, both "before" and "after". Then >>> I compared the log files, to see the impact of the addition of exactly >>> one UINT32 dynamic PCD to the PCD HOB, on temporary PEI memory usage. >>> >>> - Diff between "before" and "after", for IA32: >>> >>>> Temp Stack : BaseAddress=0x814000 Length=0x4000 >>>> Temp Heap : BaseAddress=0x810000 Length=0x4000 >>>> Total temporary memory: 32768 bytes. >>>> temporary memory stack ever used: 16384 bytes. >> >> The code that performs this check looks broken to me btw: it looks for >> INIT_CAR_VALUE on the stack, but it is not clear to me where the stack >> is initialised with this value, and that fact that we always seem to >> use exactly the entire stack looks suspicious as well. >> >> So perhaps you could reuse some of that space for the heap as well? >> >> #define INIT_CAR_VALUE 0x5AA55AA5 > > Possibly. Two observations hold me back: > > - I did notice that "temporary memory stack ever used" was always the > full size. It seemed wrong (as you say), but without the actual usage > being reported, I wouldn't know how much to reassign from stack to heap. > This change --- a/ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S +++ b/ArmPlatformPkg/PrePeiCore/AArch64/PrePeiCoreEntryPoint.S @@ -84,4 +84,11 @@ _PrepareArguments: _SetupPrimaryCoreStack: mov sp, x1 - b _PrepareArguments + + MOV64 (x8, FixedPcdGet32(PcdCPUCorePrimaryStackSize)) + MOV64 (x9, 0x5aa55aa55aa55aa5) +0:sub x10, sp, x8 + subs x8, x8, #16 + stp x9, x9, [x10] + b.mi _PrepareArguments + b 0b gets me from Total temporary memory: 16352 bytes. temporary memory stack ever used: 8176 bytes. temporary memory heap used for HobList: 4720 bytes. to Total temporary memory: 16352 bytes. temporary memory stack ever used: 4820 bytes. temporary memory heap used for HobList: 4720 bytes. so it should simply be a matter of seeding the stack with the correct magic value in the startup code. Regardless of whether this is of any use to you in this particular case, I intend to add this to the ARM startup code. So thanks for spotting this! > - OVMF SEC currently halves the temp RAM between stack and heap. It > doesn't look hard to update. But, I'm not attracted to tracking down > other occurrences (if any) of same assumption in other (non-OvmfPkg) > parts of edk2. > I would not expect there to be many platform wide assumptions regarding how SEC deals with this, but of course, I am not coming from the x86 world :-)