Re: [libvirt] [PATCH v2] qemu: Allow UEFI paths to be specified at compile time
On Wed, Dec 03, 2014 at 12:39:39PM +0100, Gerd Hoffmann wrote:
Hi,
> A directory of metadata files would work, but I think we could manage with
> something simpler. Just have a standard path naming convention that firmware
> installs should follow. eg any firmware for use with QEMU should use a dir
> named per the architecture it supports
>
> eg
>
> /usr/share/qemu/firmware/<arch>/<name>.{img,vars}
Problem #1: sometimes it's .../qemu-kvm/...
Today not a problem because libvirt doesn't need to know in the first
place where the qemu data directory is.
Hmm, so it occurrs to me that this is really about detecting what
BIOS capabilities QEMU is able to support. We have standardized on
interogating QEMU via QMP for this purpose. So rather than libvirt
having to know about paths, or config files, I wonder if QEMU should
own this knowledge and then expose the information via QMP.
eg, libvirt can issue a 'query-bios-images' QMP command and this
returns info on all installed BIOS images that QEMU can identify.
QEMU can use well known filesystem paths, or it can use metadata
config files, or something else. It can change this at will
without impacting libvirt or other non-libvirt apps since they'd
be insulated from the underlying representation by always using
QMP.
> So EDK would provide
>
> /usr/share/qemu/firmware/i686/edk2.img
> /usr/share/qemu/firmware/i686/edk2.vars
> /usr/share/qemu/firmware/i686/seabios.img
Problem #2: How does libvirt know whenever the image is for -bios or
-pflash?
We could encode that in the path / filename too.
While being at it we might also consider supporting non-raw formats for
flash, i.e. have edk2.{code,vars}.{raw,qcow2}.
This again makes me prefer interogating QEMU via QMP to get all the
various pieces of information.
> This makes it trivial to enumerate all the firmware images available
> for a particular architecture - just scan the appropriate directory
> for files ending in ".img".
I'm not convinced it is that much easier in the end. Most of the work
probably is encoding the firmware list in the capabilities anyway ...
Also you can't easily attach meta data like a description, or give it a
nice name. On filesystem level I'd prefer keep the names simliar or
identical to what the edk2 build produces, but in the gui it is probably
better to present 'UEFI' instead of 'edk2' or 'ovmf' to the user.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|