[libvirt] [PATCH 1/2] qemu: Add AAVMF32 to the list of known UEFIs

[dann frazier]

On Mon, Jul 10, 2017 at 12:23 PM, John Ferlan <jferlan at redhat.com> 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