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