Re: [Qemu-devel] [RFC] Defining firmware (OVMF, et al) metadata format & file

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

On Thu, Mar 08, 2018 at 12:10:30PM +0100, Laszlo Ersek wrote:
> (
> Ard, the thread starts here:
> 
> http://mid.mail-archive.com/20180307144951.d75lo5rgzi2vf27z@eukaryote
> )
> 
> On 03/07/18 15:49, Kashyap Chamarthy wrote:
> > Problem background
> > ------------------
> > 
> > The various OVMF binary file names and paths are slightly different[+]
> > for each Linux distribution.  And each high-level management tool
> > (libguestfs, oVirt, `virt-manager` and OpenStack Nova) is inventing its
> > own approach to detect and configure the said OVMF files.  This email
> > thread is about arriving at some common understanding to make this a bit
> > more "unified" by addressing these needs in QEMU and libvirt.
> 
> I've read Dan's message <20180307151836.GK20201@redhat.com> and Gerd's
> messages <20180308075245.lgzredyhn2paawg4@sirius.home.kraxel.org>,
> <20180308074507.nwho4tddsoxb3b7v@sirius.home.kraxel.org>.
> 
> Those seem to cover everything, I don't have anything to add wrt.
> purpose, use case, flexibility etc.
> 
> I suggest (or agree) that the property list be composed of free-form
> name=value pairs (at least conceptually). I understand Gerd is proposing
> a QAPI schema for this, so maybe do { property_name : "foo",
> property_value : "bar" }, or similar. The registry of properties (names,
> possible values, meanings) should be kept separate (although possibly
> still under QEMU).
> 
> For OVMF (x86), I guess the initial set of properties should come from
> the "-D FOO[=BAR]" build flags that OVMF currently supports. (The list
> might grow or change incompatibly over time, so this is just a raw
> starter idea.)

I really don't want to see us using firmware implementation specific
property names in these files. It means libvirt will require knowledge
of what each different firmware's property names mean.

We need to have some core standardized set of property names that can
be provided by any firmware implementation using the same terminology.

If we want to /also/ provide some extra firmeware-specific property
names that would be ok for informative purposes, but when lbivirt is
picking which firmware file to use, it would only ever look at the
standardized property names/values.

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