From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 96BD42195DA61 for ; Tue, 2 May 2017 11:22:27 -0700 (PDT) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga105.jf.intel.com with ESMTP; 02 May 2017 11:22:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,280,1491289200"; d="scan'208";a="82940652" Received: from rfrapple-mobl1.amr.corp.intel.com (HELO localhost) ([10.255.75.93]) by orsmga004.jf.intel.com with ESMTP; 02 May 2017 11:22:26 -0700 MIME-Version: 1.0 To: Laszlo Ersek , edk2-devel-01 Message-ID: <149374934642.31820.11722993986360080415@jljusten-skl> From: Jordan Justen In-Reply-To: Cc: Gary Ching-Pang Lin References: <20170429201500.18496-1-lersek@redhat.com> <030f8312-35ce-5c86-205c-2ee6c0b5ab8b@redhat.com> <149358697668.23065.6363402854761002239@jljusten-skl> <149365940885.25909.1007719045522991203@jljusten-skl> <88d156c9-c18e-c4e8-b9a3-641a1b6b4102@redhat.com> <149366640991.26266.1222435765632598609@jljusten-skl> <62f44903-c06a-fb0f-0761-17cf9107620e@redhat.com> <149368192252.29568.13017173745830665833@jljusten-skl> User-Agent: alot/0.5.1 Date: Tue, 02 May 2017 11:22:26 -0700 Subject: Re: [PATCH 2/3] OvmfPkg: introduce FD_SIZE_4MB (mainly) for Windows HCK 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: Tue, 02 May 2017 18:22:27 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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