Re: PATCH: Increase System Firmware Max Size

[Daniel P . Berrangé]

On Fri, Sep 11, 2020 at 04:06:02PM +0100, Dr. David Alan Gilbert wrote:
> * Laszlo Ersek (lersek@redhat.com) wrote:
> > On 09/11/20 10:34, Dr. David Alan Gilbert wrote:

> > > it doesn't have any pretty graphics
> > > or snazzy stuff,
> > 
> > Which is arguably completely superfluous on every possible platform one
> > can imagine. On the other hand, if you want a real serial port on
> > workstation class hardware, you may have to order a separate part (if
> > you are lucky and you *can* order one). Serial-over-LAN is a complete
> > non-replacement.
> > 
> > The reason (should I say: excuse) for the firmware to exist is to (a)
> > boot operating systems, (b) abstract away some ugly platform-specific
> > hardware for OS runtime (by providing ACPI and SMBIOS descriptions, and
> > a *small* set of runtime services). We can maybe add (c) "root of trust".
> > 
> > In practice, physical firmware is becoming the hw vendor's OS before
> > (and under) your OS, one you cannot replace, and one whose updates can
> > brick your hardware. Permitting the same feature creep on virtual
> > platforms is wrong.
> 
> On the firmware you develop that choice is fine; but there's no reason
> to force that restriction onto others.
> 
> > > or have to survive configuring lots of hardware; also
> > > I'm aware of other companies who are looking at putting big blobs
> > > of stuff in firmware for open uses;
> > 
> > Key term being "open uses". Let us see them.
> 
> Well yes, I think we know who we're speaking about here and we're
> working on it.

I don't think we need to dictate that firmware used with QEMU has to be
open source.

If someone wants to use a closed source firmware that is fine. They simply
can't expect us to help debug problems in QEMU when using the closed source
firmware, without first demonstrating it with an open source firmware we can
see.

> > > so I don't see a problem with
> > > changing this limit from the QEMU side of things.
> > 
> > I do. Software and data always expand to consume all available space,
> > and it's going to cause a conflict between UEFI features and platform
> > MMIO sooner or later. Then I'll get the privilege of shuffling around
> > the crap in OVMF (all of which is "indispensable" or course).
> > 
> > If we ever go down this route, it needs to benefit open source directly
> > and significantly.
> 
> Being able to use QEMU to let vendors debug their platform firmware is a
> perfectly reasonable use of QEMU; maybe not of your OVMF build - we
> need to keep the restrictions on the two separate.

Agreed, I can understand the motivation to not want to change the QEMU
defaults, but I don't see why we should have this as a hard coded
limit that is not runtime configurable.

IOW, why can't we keep our current default and provide a machine type
property "firmware_max_size" which users can opt-in to setting if
their particular firmware exceeds normal defaults. That won't impact
us for migration compat in any way, and lets users have flexibility t
do what they want.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|