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

[Laszlo Ersek]

On 01/17/19 15:09, Gerd Hoffmann wrote:
> On Thu, Jan 17, 2019 at 01:54:51PM +0100, Laszlo Ersek 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.
>>
>> 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?
> 
> Ah, right, the arm versions can't be used as-is with pflash.  In my rpm
> builds I've named the padded version "QEMU_EFI-pflash.raw".  Using
> .padded looks fine to me too.
> 
> Other idea:  Does it make sense to use qcow2 for the pflash images?
> i.e. "qemu-img create -f qcow2 -b QEMU_EFI.fd -F raw QEMU_EFI.qcow2 64M"?

That's a long story.

In a perfect world, the answer would be, "qcow2 (and all its features)
make perfect sense for pflash images". In the world we have however,
"savevm" exists, which might dump live guest RAM into whichever qcow2
disk it finds first. See
<https://bugzilla.redhat.com/show_bug.cgi?id=1214187>.

(I apologize to any non-RedHatters reading this; that's a private RHBZ
for some obscure reason, and I dare not open it up myself.)

See also libvirt commit 9e2465834f4b ("qemu: snapshot: Forbid internal
snapshots with pflash firmware", 2017-03-24).

So, for now, it remains the case that we're better off with raw, at
least for the writeable (=varstore) pflash chip.

In addition, when libvirt composes the cmdline, it specifies format=raw
for unit=0 (i.e., firmware image pflash) as well. (That's actually a
good thing, because we shouldn't auto-detect the format, and qcow2 is
out (for now), so we should specify format=raw. In the future, the
domain XML schema may have to be extended with "format" too.)

... For now, it's probably best to check the unpadded FDs into git, and
pad them only in "make install".

Thanks,
Laszlo