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@xxxxxxxxxx> > >--- > > > >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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list