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>,
	edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Subject: Re: [PATCH 2/3] OvmfPkg: introduce FD_SIZE_4MB (mainly) for Windows HCK
Date: Tue, 02 May 2017 11:22:26 -0700	[thread overview]
Message-ID: <149374934642.31820.11722993986360080415@jljusten-skl> (raw)
In-Reply-To: <c5df3c55-bde6-71d9-9104-5a095f3e820a@redhat.com>

On 2017-05-02 07:39:04, Laszlo Ersek wrote:
> 
> I wouldn't mind if we made more room for the varstore in the 2MB build,
> even at the expense of FVMAIN_COMPACT, if we also kept the current 2MB
> build the default, so that the "new" (incompatible) 2MB build doesn't
> come as a surprise to unsuspecting downstreams.
> 
> Regarding the 4MB build:
> - we can discuss that on top of the above "new" 2MB build,
> - we can discuss it instead of the above "new" 2MB build,
> - we can postpone it for now, for upstream.

I was hoping there was a way to avoid the need to add 4MB, but you
needing to support the layout until 2024 really adds risk to the 2MB
image. I think there is a decent chance 2MB would work until then, but
I can also see how it adds significant risk.

If we are adding the 4MB layout, then we may as well make it the
default for debug builds. I'm not sure what to do about 2MB then. In
the short term, I say we do nothing. Later, after 4MB is established
as the default, maybe we continue to do nothing, or perhaps resize the
varstore to 120~128k, or perhaps just remove the layout entirely.

> If you do agree that a 4MB build should be offered in upstream, then I'm
> proposing my proposal (obviously :) ). If your main focus is the "new"
> 2MB build, and beause mine is the 4MB build, perhaps we aren't even
> disagreeing as much, since this doesn't have to be an either-or. If you
> have specific observations for the 4MB structure I proposed, I'd be glad
> to hear those as well.

I feel fairly confident of the 4MB image supporting your code size
needs until 2024. What seems less certain in future varstore
requirements. Right now the requirement is 120~128k. I think rather
than 248k in the 4MB layout, we should make it 256k. (Since these
kinds of things often progress in powers-of-two.) It will make for a
couple unfriendly offsets, but it seems worth it to avoid being 8k shy
of the next power-of-two size.

In my other email, I mentioned the event-log. I did ask around a bit
about this, but I didn't find anyone willing to fight for more space.
Therefore, I think we should just keep it at 4k.

-Jordan


  reply	other threads:[~2017-05-02 18:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-29 20:14 [PATCH 0/3] OvmfPkg: add FD_SIZE_4MB for Windows HCK SB tests, and for future proofing Laszlo Ersek
2017-04-29 20:14 ` [PATCH 1/3] OvmfPkg/OvmfPkg.fdf.inc: extract VARS_LIVE_SIZE and VARS_SPARE_SIZE macros Laszlo Ersek
2017-04-29 20:14 ` [PATCH 2/3] OvmfPkg: introduce FD_SIZE_4MB (mainly) for Windows HCK Laszlo Ersek
2017-04-30  0:48   ` Jordan Justen
2017-04-30 14:42     ` Laszlo Ersek
2017-04-30 21:16       ` Jordan Justen
2017-05-01 10:51         ` Laszlo Ersek
2017-05-01 17:15           ` Jordan Justen
2017-05-01 17:23           ` Jordan Justen
2017-05-01 18:40             ` Laszlo Ersek
2017-05-01 19:20               ` Jordan Justen
2017-05-01 23:07                 ` Laszlo Ersek
2017-05-01 23:38                   ` Jordan Justen
2017-05-02 14:39                     ` Laszlo Ersek
2017-05-02 18:22                       ` Jordan Justen [this message]
2017-05-02 19:31                         ` Laszlo Ersek
2017-05-02 21:45                           ` Jordan Justen
2017-05-03 13:46                             ` Laszlo Ersek
2017-05-01  0:06     ` Laszlo Ersek
2017-04-29 20:15 ` [PATCH 3/3] OvmfPkg: raise max variable size (auth & non-auth) to 33KB for FD_SIZE_4MB Laszlo Ersek

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=149374934642.31820.11722993986360080415@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