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

[Cole Robinson]

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

ccing danpb, gerd, laszlo incase anyone has further thoughts

- Cole