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::243; helo=mail-it0-x243.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 386462034D83F for ; Mon, 13 Nov 2017 02:05:44 -0800 (PST) Received: by mail-it0-x243.google.com with SMTP id f187so8773954itb.1 for ; Mon, 13 Nov 2017 02:09:51 -0800 (PST) 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=nQwR6DmPRUr/woVE4MGJQpTPrZ3FD3UrWTtbIc2c92M=; b=BhP/0qeI6bFU8PNVN7v2sMpeWcGjJLIockuf2tAhLJMfTHAfv9bct9k8t8hobyh+yb rdVxK57UgGTqjWAEnuMN3dSgqdRj1l6T37IhMs1HiG7XRUx/IPjbhuTO/Ivmpc9fpmv5 /KwmbegAAHDgneXMZqlTcLsRtf9pcRGcIR1/g= 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=nQwR6DmPRUr/woVE4MGJQpTPrZ3FD3UrWTtbIc2c92M=; b=EVwlib6LqRlQ69jQt7neaQkd0QZ2UT/dDPnmpNlNN3bF1dV03kDMiAkOaZSmsCFhpr E1Jx8NbpPQCEWjyX+mP7btcGy7FsHykPdQl5TOGJZ0arjrYJOn8ufOhdWZEg7lJLsbAj 232SfkZpEMrpVMK9GcvOVUYHFI4+x+jdQoz6Ttd+24n928lCi0FbT10sXJXrM5d0zeKf Qo88JKKCTqnwbIOTLmr/VcI281v665FUFYWhcs0qXPIpHJEizUgSpS5LnFtxZnPToaT/ tuglRms2EqcR4jaHgqUfGiqV9f2Atc4KKbWmBwSZL6s36qs4HNxecdMpiLCjbEd1GFMb /YPQ== X-Gm-Message-State: AJaThX5I39YiZc2f73hCQyZNP6+fZzA3bk91ca766fym/0UsBG38rCKx 5qMxwmX91e7EcH0ifipEFcPc+TvtTXf+MoaADC035g== X-Google-Smtp-Source: AGs4zMZTaP1kRI7x/7KxnQFyU4Ea4qpNiI0Jrp3UE5IS9pHGuOxsIB1JOaUvwS1Y0MBm23JRvvoEH+RXwVtiE0kWVm8= X-Received: by 10.36.145.203 with SMTP id i194mr9819097ite.73.1510567790256; Mon, 13 Nov 2017 02:09:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.20 with HTTP; Mon, 13 Nov 2017 02:09:49 -0800 (PST) In-Reply-To: <151056410867.15809.659701894226687543@jljusten-skl> References: <20171110154908.306-1-lersek@redhat.com> <151043270153.17841.16763408160801933614@jljusten-skl> <151043786891.19895.6326436717816766532@jljusten-skl> <151056410867.15809.659701894226687543@jljusten-skl> From: Ard Biesheuvel Date: Mon, 13 Nov 2017 10:09:49 +0000 Message-ID: To: Jordan Justen Cc: Laszlo Ersek , edk2-devel-01 , Ruiyu Ni Subject: Re: [PATCH 0/4] OvmfPkg: measure temp stack usage, restore temp RAM to 64KB 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: Mon, 13 Nov 2017 10:05:45 -0000 Content-Type: text/plain; charset="UTF-8" On 13 November 2017 at 09:08, Jordan Justen wrote: > On 2017-11-12 02:58:37, Ard Biesheuvel wrote: >> On 11 November 2017 at 22:04, Jordan Justen wrote: >> > On 2017-11-11 12:38:21, Jordan Justen wrote: >> >> On 2017-11-10 07:49:04, Laszlo Ersek wrote: >> >> > The first three patches enable the PEI_CORE to report OVMF's temp >> >> > SEC/PEI stack and heap usage. >> >> > >> >> > - This depends on the new fixed PCD "PcdInitValueInTempStack", >> >> > recently added for >> >> > >> >> > ("INIT_CAR_VALUE should be defined in a central location"). >> >> > >> >> > - Ard recently implemented the same in ArmPlatformPkg, for >> >> > ("measure temp >> >> > SEC/PEI stack usage"). >> >> > >> >> > The last (fourth) patch adapts OVMF to the larger MtrrLib stack demand >> >> > that originates from commit 2bbd7e2fbd4b ("UefiCpuPkg/MtrrLib: Update >> >> > algorithm to calculate optimal settings", 2017-09-27). OVMF's temp RAM >> >> > size is restored to the historical / original 64KB. >> >> > >> >> > This work is tracked in >> >> > ("measure temp >> >> > SEC/PEI stack usage; grow temp SEC/PEI RAM"), with links to related >> >> > mailing list discussions. >> >> > >> >> > Repo: https://github.com/lersek/edk2.git >> >> > Branch: temp_ram_tweaks >> >> > >> >> > Cc: Ard Biesheuvel >> >> > Cc: Jordan Justen >> >> > Cc: Ruiyu Ni >> >> > >> >> > Thanks >> >> > Laszlo >> >> > >> >> > Laszlo Ersek (4): >> >> > OvmfPkg/Sec/Ia32: free up EAX for other uses while setting up the >> >> > stack >> >> > OvmfPkg/Sec/Ia32: seed the temporary RAM with PcdInitValueInTempStack >> >> > OvmfPkg/Sec/X64: seed the temporary RAM with PcdInitValueInTempStack >> >> >> >> I'd like to try a different option for these 3. Can you hold off a bit >> >> before pushing this series? >> > >> > I think we should use a C based approach instead, like in the attached >> > patch. >> > >> >> I'm not sure: having to abuse SetJump () > > True, that was annoying. It seems like we could have AsmReadEsp and > AsmReadRsp in BaseLib since we have AsmReadSp for IPF. > >> and having to leave an >> arbitrary 512 byte window both seem pretty good reasons to stick with >> assembly. > > Also true. I chose 512 because it seemed like more than SetMem32 could > reasonably need, but also much below the minimum I would expect PEI to > use. (It seemed that around 4k ended up being used.) > >> Is your concern that the stack gets cleared in RELEASE builds as well? > > No. I just prefer if we can use C rather than assembly whenever it is > reasonable. > No discussion there. But in my opinion, anything involving the absolute value of the stack pointer does not belong in C.