[libvirt] [PATCH v2] qemu: Allow UEFI paths to be specified at compile time

[Daniel P. Berrange]

On Tue, Dec 02, 2014 at 02:57:15PM -0500, Cole Robinson wrote:
> On 12/02/2014 07:51 AM, Michal Privoznik wrote:
> >Up until now there are just two ways how to specify UEFI paths to
> >libvirt. The first one is editing qemu.conf, the other is editing
> >qemu_conf.c and recompile. Therefore, two new configure options
> >are invented: --with-default-loader --with-default-nvram.
> >
> >At the same time, the list of default paths is extended to AAVMF.
> >which is an aarch64 port of OVMF.
> >
> >Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> >---
> >
> >diff to v1:
> >-introduce configure options too
> >
> 
> Hmm, I'm not sure if just allowing one pair at compile time is sufficient.
> 
> While RHEL only cares about KVM, which means host arch == guest arch, in
> Fedora we want to facilitate aarch64 VMs on x86. So we want to teach libvirt
> about an x86 uefi->vars mapping as well as an aarch64 uefi->vars mapping
> regardless of the host arch.
> 
> But even if both are tracked, things would still be suboptimal for tools
> since we don't know what binaries are expected for what VM arch without
> scraping file names. Maybe domcapabilities could report architecture as
> well, but there's no way to make that distinction with this configure
> option. This situation is kind of a mess, and even messier if anyone wanted
> to advertise even more uefi options like csm for example.
> 
> Gerd's idea of a firmware.d directory, where packages would drop config
> files describing their pairs with extra metadata like a description,
> associated arch, etc:
> 
> https://www.redhat.com/archives/virt-tools-list/2014-September/msg00145.html
> 
> That allows keeping all the relevant data contained with firmware packages,
> and we could make libvirt automatically pick up mappings when a new package
> is installed, expose them via capabilities/domcapabilities, etc. But it's a
> decent chunk of work...

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}

So EDK would provide

  /usr/share/qemu/firmware/i686/edk2.img
  /usr/share/qemu/firmware/i686/edk2.vars
  /usr/share/qemu/firmware/x86_64/edk2.img
  /usr/share/qemu/firmware/x86_64/edk2.vars

The AArch64 UEFI would be

  /usr/share/qemu/firmware/aarch64/edk2.img
  /usr/share/qemu/firmware/aarch64/edk2.vars

The legacy SeaBIOS would be

  /usr/share/qemu/firmware/i686/seabios.img
  /usr/share/qemu/firmware/x86_64/seabios.img

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".

If we want to have a notion of "default" firmware, we could say that
'default.img' should be a symlink to the default firmware, probably
seabios.img for the forseeable future.

If you want to be really advanced you could let update-alternatives
manage the default.img symlink, much as I hate update-alternatives :-)

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