public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Jordan Justen <jordan.l.justen@intel.com>
To: Laszlo Ersek <lersek@redhat.com>, Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	edk2-devel@lists.01.org, Jiewen Yao <jiewen.yao@intel.com>,
	Michael D Kinney <michael.d.kinney@intel.com>
Subject: Re: [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings
Date: Wed, 08 Nov 2017 17:53:57 -0800	[thread overview]
Message-ID: <151019243761.10467.634318081879242382@jljusten-skl> (raw)
In-Reply-To: <03e369bb-77c4-0134-258f-bdae62cbc8c5@redhat.com>

On 2017-11-08 17:36:01, Laszlo Ersek wrote:
> Hi Ray,
> 
> On 10/12/17 10:48, Ruiyu Ni wrote:
> > The new algorithm converts the problem calculating optimal
> > MTRR settings (using least MTRR registers) to the problem finding
> > the shortest path in a graph.
> > The memory required in extreme but rare case can be up to 256KB,
> > so using local stack buffer is impossible considering current
> > DxeIpl only allocates 128KB stack.
> > 
> > The patch changes existing MtrrSetMemoryAttributeInMtrrSettings() and
> > MtrrSetMemoryAttribute() to use the 4-page stack buffer for
> > calculation. The two APIs return BUFFER_TOO_SMALL when the buffer
> > is too small for calculation.
> 
> [snip]
> 
> > +#define SCRATCH_BUFFER_SIZE           (4 * SIZE_4KB)
> 
> [snip]
> 
> >  RETURN_STATUS
> >  EFIAPI
> > -MtrrSetMemoryAttribute (
> > +MtrrSetMemoryAttributeInMtrrSettings (
> > +  IN OUT MTRR_SETTINGS       *MtrrSetting,
> >    IN PHYSICAL_ADDRESS        BaseAddress,
> >    IN UINT64                  Length,
> >    IN MTRR_MEMORY_CACHE_TYPE  Attribute
> >    )
> >  {
> >    RETURN_STATUS              Status;
> > +  UINT8                      Scratch[SCRATCH_BUFFER_SIZE];
> 
> [snip]
> 
> (This patch is now commit 2bbd7e2fbd4b.)
> 
> Today I managed to spend time on
> 
>   https://bugzilla.tianocore.org/show_bug.cgi?id=747
> 
> (which is in turn based on the earlier mailing list thread
> 
>   [edk2] dynamic PCD impact on temporary PEI memory
>   https://lists.01.org/pipermail/edk2-devel/2017-October/016213.html
> ).
> 
> While writing the patches, I found the root cause of BZ#747:
> "OvmfPkg/PlatformPei" calls MtrrLib APIs, and due to the above 16KB
> stack allocation, MtrrLib overflow's OVMF's 16KB (total) temp SEC/PEI
> stack.

I thought it was considered bad form to use a significant portion of
the stack (> ~100 bytes) via local variables. This used to
occasionally break MSVC builds as MS would insert a stack check call
if the locals size exceeded some threshold.

For a BASE library, I think this should go beyond "bad form" and into
not allowed.

-Jordan


  reply	other threads:[~2017-11-09  1:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12  8:48 [PATCH 0/4] Update MTRR algorithm to calculate optimal settings Ruiyu Ni
2017-10-12  8:48 ` [PATCH 1/4] UefiCpuPkg/MtrrLib: refine MtrrLibProgramFixedMtrr() Ruiyu Ni
2017-10-12  8:48 ` [PATCH 2/4] UefiCpuPkg/MtrrLib: Optimize MtrrLibLeastAlignment() Ruiyu Ni
2017-10-12  8:48 ` [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings Ruiyu Ni
2017-11-09  1:36   ` Laszlo Ersek
2017-11-09  1:53     ` Jordan Justen [this message]
2017-11-09  3:04       ` Ni, Ruiyu
2017-11-09  3:19         ` 答复: " Fan Jeff
2017-11-09  6:55         ` Jordan Justen
2017-11-09  7:11           ` Ni, Ruiyu
2017-11-09 13:15             ` Laszlo Ersek
2017-11-10  0:52               ` Ni, Ruiyu
2017-11-10 14:45                 ` Laszlo Ersek
2017-10-12  8:48 ` [PATCH 4/4] UefiCpuPkg/MtrrLib: Skip Base MSR access when the pair is invalid Ruiyu Ni
2017-10-16  3:02 ` [PATCH 0/4] Update MTRR algorithm to calculate optimal settings Yao, Jiewen
2017-10-16  3:25   ` Ni, Ruiyu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=151019243761.10467.634318081879242382@jljusten-skl \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox