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

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(a)redhat.com&gt; >>--- >> >>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.