On 12/02/14 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@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, If I remember correctly, a third field was considered at some point for the nvram element type. Firmware binary, varstore template, and (as 3rd field) guest architecture. I felt that such a third field was both insufficient and unnecessary. Insufficient because even if you filter the list for the guest arch that the user wants, you might end up with several options: - below you mention CSM vs. pure-UEFI build, correctly; - there's also "secure boot enabled build" vs. "secure boot disabled build" (where those binaries also need different variable store templates, even on the same architecture), - some ad-hoc builds, - etc. Therefore, my thinking went, you can't avoid presenting the user with a list of firmwares to pick from anyway, and that dialog then makes the filtering & any further fields in "nvram" unnecessary. Let the user worry about picking a firmware that he likes, covering architecture and all other aspects. Of course when I had the above thoughts I didn't know yet that you abhor the nuts n' bolts approach... :) > 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... Probably. It still wouldn't save you from asking the user about his firmware preference. (The "CSM/pure-UEFI, secure boot enabled/disabled, distro-shipped / 3rd party build" decision would still need to be made at guest creation time.) IMO picking a firmware (a binary with its associated varstore template) is not much different from picking an installer ISO. If you pick an installer ISO for the wrong guest architecture (like an x86_64 Fedora LiveCD for an aarch64 guest), it won't boot. Which means that the user *already* needs to be aware of mixing & matching guest architectures. I think the same approach should work for firmware images as well. Let the user worry about it. Thanks Laszlo > ccing danpb, gerd, laszlo incase anyone has further thoughts > > - Cole -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list