Re: PATCH: Increase System Firmware Max Size

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Sep 11, 2020 at 06:06:27PM +0200, Laszlo Ersek wrote:
> On 09/11/20 17:23, Daniel P. Berrangé wrote:
> 
> > 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.
> 
> Technically, this is fine, in my opinion.
> 
> My concerns (in distilled form, this time):
> 
> - The change increases maintenance burden.

I think that is so marginal that its lost in the noise compared to
everything else that's done in QEMU. Essentially someone can pick
a value that is so large that it tickles some other problem in QEMU
or their firmware. We're not promising to fix such problems if they
occurs. It'll be perfectly valid to say "dont do that" if someone
sets a value that breaks something else and we don't consider it
worth the time to investigate and fix.

> - The change does not benefit most users of QEMU, as the intended guest
> payload will not available to most of them at all (regardless of
> licensing terms).

I think that's only relevant if the change is imposing a significant
maint burden which needs to be justified. Not the case here IMHO.

> - The existence of the property may entice OVMF users to ask us to
> enlarge the *current* OVMF firmware platform and to pack more stuff in
> it. That is not OK. My counter-proposal ("please contribute a new
> platform DSC/FDF under OvmfPkg, and assume co-reviewership for it")
> would almost certainly not be acted upon.

I don't see this is relevant. If OVMF maintainers want to reject
feature proposals they have the right to do that regardless of what
QEMU sets for max image size. As you say earlier, the existing size
limit is already enourmous compared to what OVMF actually uses, so
if this was a real problem it'd already exist.

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 :|