On Mon, Jul 10, 2017 at 12:23 PM, John Ferlan <jferlan@xxxxxxxxxx> wrote: > > > On 06/28/2017 12:02 PM, dann frazier wrote: >> Add a path for UEFI VMs for AArch32 VMs. This is the path Debian is >> currently using in experimental. libvirt is the de facto canonical > > "experimental"? Hi John! experimental is a staging archive for Debian. I uploaded it there because Debian was in freeze at the time, not because we're continuing to weigh options. > Is this written in stone some where yet? I'm not sure what qualifies as stone here. I've planted a flag via Debian, and tried to build consensus on the cross-distro list: https://lists.linaro.org/pipermail/cross-distro/2017-April/000865.html As you can see, mostly crickets, other than a suggestion to lock it in via libvirt. >> location for where distros should place these firmware images, so let's >> define this path here to try and minimize distro fragmentation. > > hmmm... This makes it appear that nothing is decided upon yet. If you know of someone else you need me to convince, point me at 'em! :) >> --- >> src/qemu/qemu_conf.c | 12 ++++++++---- >> 1 file changed, 8 insertions(+), 4 deletions(-) >> > > How would anyone know to use this unless qemu.conf was modified to > describe the possibility? > > See commit id '436dcf0b' for when AAVMF was originally added keeping in > mind that commit id 'f2f1e388' fixed the names/path. This will give a > better idea of what additional files should be changed. OK, thanks - I'll take a look. >> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c >> index 73c33d6788..c1bd91935b 100644 >> --- a/src/qemu/qemu_conf.c >> +++ b/src/qemu/qemu_conf.c >> @@ -130,6 +130,8 @@ void qemuDomainCmdlineDefFree(qemuDomainCmdlineDefPtr def) >> #define VIR_QEMU_OVMF_SEC_NVRAM_PATH "/usr/share/OVMF/OVMF_VARS.fd" >> #define VIR_QEMU_AAVMF_LOADER_PATH "/usr/share/AAVMF/AAVMF_CODE.fd" >> #define VIR_QEMU_AAVMF_NVRAM_PATH "/usr/share/AAVMF/AAVMF_VARS.fd" >> +#define VIR_QEMU_AAVMF32_LOADER_PATH "/usr/share/AAVMF/AAVMF32_CODE.fd" >> +#define VIR_QEMU_AAVMF32_NVRAM_PATH "/usr/share/AAVMF/AAVMF32_VARS.fd" > > Not that it's in my wheelhouse, but I'm somewhat surprised by the notion > to have the AAVMF directory have both 64 and 32 bit files... Guess I'm > surprised it's not AAVMF32/ since it would seem easier to be able to > have consistent names of "%s_VARS.fd" and "%s_CODE.fd" to go with the > /usr/share/%s/ path when trying to "build" a name. I've asked the > QEMU/OVMF maintainer in this space and get his insights as well. One of my goals here is to avoid further pollution of the /usr/share directory. I've had complaints from other Debian Developers about the existing AAVMF and OVMF subdirs, but we've retained this for compatibility with libvirt upstream. -dann -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
