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

Daniel P. Berrange berrange at redhat.com
Wed Dec 3 12:43:17 UTC 2014


On Wed, Dec 03, 2014 at 01:35:18PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > Hmm, so it occurrs to me that this is really about detecting what
> > BIOS capabilities QEMU is able to support.
> 
> IMHO this isn't a property of qemu, but a property of the firmware.
> 
> Thats why I think the firmware packages should include some config file
> with the meta data.

It feels related to QEMU because you need to have info about whether
to use -bios or -pflash, and info about the format raw vs qcow2 and
whether the firmware is compatible with the particular system emulator
arch.

> > 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.
> 
> We could have qemu parse the firmware config files and export this via
> qmp, but I fail to see the benefits this extra indirection brings us.

The location of the firmware and/or firmware config files can vary
depending on what $PREFIX QEMU was installed in. I don't think that
external apps should have to care about where the firmware or the
firmware config files are installed - that's QEMU's build time knowledge.
All an mgmt app should need to care about is the path to the QEMU binary
and from that it should be able to interrogate QEMU to find out
everything else and not have to hardcode any info like paths to
extra assets related to QEMU.

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




More information about the libvir-list mailing list