Re: [Qemu-devel] [PATCH 11/14] tests: acpi: add AVMF firmware blobs

[Igor Mammedov <imammedo@redhat.com>]

On Thu, 17 Jan 2019 13:54:51 +0100
Laszlo Ersek <lersek@redhat.com> wrote:

> On 01/17/19 11:22, Gerd Hoffmann wrote:
> >   Hi,
> >   
> >>>>>>  create mode 100644 pc-bios/avmf.img
> >>>>>>  create mode 100644 pc-bios/avmf_vars.img    
> >>>>>
> >>>>> "AVMF" is not a great name. "AAVMF" is a downstream name alright, but
> >>>>> many dislike it in upstream use. "edk2-aarch64" or "edk2-ArmVirtQemu"
> >>>>> would be more precise, but those are verbose. Sigh, why are names so
> >>>>> hard. What does everyone think?  
> >>>> I'm fine with either version.  
> > 
> > How about placing them in pc-bios/efi-$arch subdirs and not renaming the
> > files, i.e. that would be ...
> > 
> > 	pc-bios/efi-aarch64/QEMU_EFI.fd
> > 	pc-bios/efi-aarch64/QEMU_VARS.fd
> > 
> > ... for arm, and ...
> > 
> > 	pc-bios/efi-x86_64/OVMF_CODE.fd
> > 	pc-bios/efi-x86_64/OVMF_VARS.fd
> > 
> > ... for x86.  
if it's non production images (i.e. openssl-less) than maybe use
tests/data/acpi instead of pc-bios for now, once we have pc-bios ones
ready we drop test specific and use production ones.

> That sounds good to me. One thing to note is that the arm/aarch64 images
> have to be padded to 64MB, so I generally append ".padded" to those file
> names. Would that be OK? Any better ideas?
Images could be pre-padded and ready for commit, wrt large size we can commit
them compressed and decompress for using in tests instead of padding padding
I'm doing now before I use them.

> >> Could we please decide for (1) vs (2), before I put more work into (1)?  
> > 
> > I'd tend to prefer (1).  

+1

> 
> Thanks. I have a patch set that's almost suitable for posting as an RFC.
> I should split the last patch and write some sensible commit messages.
> 
> BTW, the bundling under pc-bios is a bit larger task than it immediately
> appears:
> 
> - there are many build options to consider (as you know perfectly well
>   :) ),
> 
> - plus now we have the "docs/interop/firmware.json" schema too, hence
>   whatever images we build for end-user consumption, should likely be
>   accompanied by metafiles that conform to this schema.
> 
> I think once we introduce the "roms/edk2" submodule for the current
> purpose, we could address the pc-bios binaries (+metafiles) in a
> separate series, on top.
> 
> Thanks,
> Laszlo
>