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:c06::242; helo=mail-io0-x242.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (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 55E622203D61D for ; Sun, 12 Nov 2017 02:54:33 -0800 (PST) Received: by mail-io0-x242.google.com with SMTP id 134so17775612ioo.0 for ; Sun, 12 Nov 2017 02:58:39 -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=uGLRrguH52QDMjT3q9iU1/gEdNn5lBxcAxcTHuw8AZQ=; b=VJrK0hW4oGQF+SZEkyg10uVnvUyodYC0jiaAgz8lBvdFMzhy0pKsvU+gI4mmEJF3LZ vI6b+R3JWvy09QozRIWrmmR0C1NMo1pDevJS7yLkydrxP4fV64Au+0vq8f3zQNxqqExg x0MEtjTX0TJuTWEb09bQRziNR9YCco3qA78Ds= 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=uGLRrguH52QDMjT3q9iU1/gEdNn5lBxcAxcTHuw8AZQ=; b=Hf2Q57DG+oItEXkRjNjfXiIVvNGovdPZy95YRaPHS78+TtFkjCvgLBX6J8Ag0l8JXC oYjoNtSTmWIGWP/Sq5ZpGRCvEWSqGfouRJHyJNnqqZx7fWhnUmwFQ9/qWzKfsfdX9+jr KN3njBcrp5KRTbkH4ULnVfftBgHtxOWnehRPGClzWjXHDXIvP+nSYEnrooDMKq9M2IMY TdSYqJwsneVQ32Oghz0aTARanU7fp/q5MP/OT24S0tGkX+lMIqRQqX6haudzWOz0biRm Ei28TutA/sLMawuKVpSUv43bPNfnnD2TXNKQFRpc9w3/lPp4h2xSdwJVKjxwU/QIWX1M 02GA== X-Gm-Message-State: AJaThX6Fs6u6m4xqAwv+MfagWb/jf8J3DKfjO4j9LsMdc3QODyEbtJ1d ObWw9zqdgGx8Df2f/cZ7Om1/qp7IPDrWDcqMCvnWrA== X-Google-Smtp-Source: AGs4zMaAl959soml+5FnlAUh/T6FIa4LYYWGnMBr2nGgdZHno03vGbUdKwk120Cq08Z59BK2BiSdUD1iAV6F3ORwEOg= X-Received: by 10.107.151.19 with SMTP id z19mr6595297iod.248.1510484318142; Sun, 12 Nov 2017 02:58:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.104.20 with HTTP; Sun, 12 Nov 2017 02:58:37 -0800 (PST) In-Reply-To: <151043786891.19895.6326436717816766532@jljusten-skl> References: <20171110154908.306-1-lersek@redhat.com> <151043270153.17841.16763408160801933614@jljusten-skl> <151043786891.19895.6326436717816766532@jljusten-skl> From: Ard Biesheuvel Date: Sun, 12 Nov 2017 10:58:37 +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: Sun, 12 Nov 2017 10:54:34 -0000 Content-Type: text/plain; charset="UTF-8" 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 () and having to leave an arbitrary 512 byte window both seem pretty good reasons to stick with assembly. Is your concern that the stack gets cleared in RELEASE builds as well? Can't we put an #ifndef MDEPKG_NDEBUG around the code instead? >> > OvmfPkg: restore temporary SEC/PEI RAM size to 64KB > > This patch is Reviewed-by: Jordan Justen > >> > >> > OvmfPkg/OvmfPkgIa32.fdf | 2 +- >> > OvmfPkg/OvmfPkgIa32X64.fdf | 2 +- >> > OvmfPkg/OvmfPkgX64.fdf | 2 +- >> > OvmfPkg/Sec/SecMain.inf | 1 + >> > OvmfPkg/Sec/Ia32/SecEntry.nasm | 19 ++++++++++++++++--- >> > OvmfPkg/Sec/X64/SecEntry.nasm | 15 +++++++++++++++ >> > 6 files changed, 35 insertions(+), 6 deletions(-) >> > >> > -- >> > 2.14.1.3.gb7cf6e02401b >> >