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

[Daniel P. Berrange]

On Wed, Dec 03, 2014 at 01:15:21PM +0100, Michal Privoznik wrote:
> On 02.12.2014 20:57, 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.
> >
> 
> It is a mess, but not for libvirt. I mean, libvirt only needs to know the
> pairs of <fw_binary>:<nvram_path> so that for given firmware binary it knows
> where to copy the nvram from. Libvirt will not stop you from specifying
> AAVMF on an x86_64 guest and I don't think it should. That's a user problem.
> Or virt-install's.

If we can go the route of querying QEMU to find out a list of installed
BIOS images though, then we would be able to avoid that problem in the
common case. ie the x86_64 QEMU would not report the aarch64 BIOS images
and vica-versa. If we report that list of BIOS images in the libvirt
emulator capabilities API call then if the app/user honours that list
they avoid the mis-match most of the time. Only if they completely ignore
the list of reporte BIOS images and directly provide their own paths
would the arch mismatch occur, and I agree that we don't need care about
that

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