From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (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 AB91D21A6F105 for ; Sun, 30 Apr 2017 14:16:17 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2017 14:16:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,397,1488873600"; d="scan'208";a="1162949840" Received: from pguermon-mobl3.ger.corp.intel.com (HELO localhost) ([10.255.77.18]) by fmsmga002.fm.intel.com with ESMTP; 30 Apr 2017 14:16:17 -0700 MIME-Version: 1.0 To: Laszlo Ersek , edk2-devel-01 Message-ID: <149358697668.23065.6363402854761002239@jljusten-skl> From: Jordan Justen In-Reply-To: <030f8312-35ce-5c86-205c-2ee6c0b5ab8b@redhat.com> Cc: Gary Ching-Pang Lin References: <20170429201500.18496-1-lersek@redhat.com> <20170429201500.18496-3-lersek@redhat.com> <149351328512.20670.1563878734495138189@jljusten-skl> <030f8312-35ce-5c86-205c-2ee6c0b5ab8b@redhat.com> User-Agent: alot/0.5.1 Date: Sun, 30 Apr 2017 14:16:16 -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: Sun, 30 Apr 2017 21:16:17 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2017-04-30 07:42:36, Laszlo Ersek wrote: > On 04/30/17 02:48, Jordan Justen wrote: > > = > > I tested a 2MB RELEASE build of OvmfIa32X64 on GCC 4.9 with: > = > RELEASE builds of virtual UEFI firmware are unsupportable in an > enterprise distribution. On tenths of occasions I've been able to > analyze OVMF and ArmVirtQemu error reports from: > - failed ASSERTs, and > - DEBUG messages > that would have been all lost in a RELEASE build. > = > QEMU (even upstream QEMU) rejects being built with NDEBUG; they consider > the asserts so important. For example, in "hw/virtio/virtio.c": We're discussing space issues, and a RELEASE build is considered unusable? I don't know what that says about the qemu project, but it certainly is not how EDK II was designed. Nevertheless, I agree that it is very nice to be able to enable DEBUG mode with the standard features included. Regarding 'standard features', see my IP6/HTTP/TLS question below. > > = > > I also tested a 2MB RELEASE build of OvmfIa32X64 on GCC 4.9 with: > > = > > * SECURE_BOOT_ENABLE=3D1 > > * NETWORK_IP6_ENABLE=3D1 > > * HTTP_BOOT_ENABLE=3D1 > > * SMM_REQUIRE=3D1 > > * TLS_ENABLE=3D1 > > = > > I don't think we consider those network items as standard > > requirements, yet there was still ~373k available. In order to bump > > the variables to 120k, we need to use 2 * (120 - 56) =3D> 128k. > = > Do I understand correctly that you suggest adding 64K to the live area, > 64K to the spare area, and decreasing FVMAIN_COMPACT by 128k? > = > I think that's a step in the wrong direction. It is starting to look less and less like 1MB is a feasible size for OVMF. Maybe going forward we'll drop 1MB, and support 2/4MB. If that happens, then it would be nice if the 2MB image covered the known requirements. > $ build \ > -b DEBUG \ > -a IA32 -a X64 \ > -p OvmfPkg/OvmfPkgIa32X64.dsc \ > -t GCC48 \ > -D SMM_REQUIRE \ > -D SECURE_BOOT_ENABLE \ > -D HTTP_BOOT_ENABLE \ > -D NETWORK_IP6_ENABLE \ > -D TLS_ENABLE Do you enable the last 3 in your production builds? I didn't think it was the case, but it would change things... > > = > > Regarding how to 'upgrade' a system from using the smaller storage > > size, I don't think there are any good answers. (Which also applies to > > the 4MB case.) > = > I agree, on both points. How would you plan to support VMs with the old 2MB layout? I guess it could be easy enough to develop a python script to resize the old layout to the new layout, but I'm not sure if it is possible for libvirt to handle the need to launch such an upgrade script.. > Which is why I think it's time to make the big jump now, and be safe for > the next several years. Why not just go for 8 MB, and give Microsoft, say 1 MB for variables? That should be 'future proof', right? :) The reality is that there's no good way to tell what Microsoft (or Red Hat) may require in the future. Right now we know that Microsoft appears to be saying 120k is good for at least the near term. I'm not against us defining a 4MB image size, but it is frustrating to be pushed into it by a single test. You did give an example of a crash dump using 10k of variable space, but even then it is not clear to me that 56k is insufficient in normal usage. Regarding your suggested 4MB layout, it seems reasonable. My only concern is, if the minimum flash size is bumped. What are the chances that 248k will cover it? Unfortunately (or fortunately), no one I've asked seem to know of any plans for the requirement to increase beyond 120k. -Jordan