Re: [PATCH 2/3] OvmfPkg: introduce FD_SIZE_4MB (mainly) for Windows HCK

[Jordan Justen <jordan.l.justen@intel.com>]

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=1
> >  * NETWORK_IP6_ENABLE=1
> >  * HTTP_BOOT_ENABLE=1
> >  * SMM_REQUIRE=1
> >  * TLS_ENABLE=1
> > 
> > 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) => 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