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