Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Jun 02, 2017 at 05:45:21PM +0200, Laszlo Ersek wrote:
> Hi,
> 
> this message is cross-posted to three lists (qemu, seabios, edk2). I'll
> follow up with three patch series, one series for each project. I'll
> cross-post all of the patches as well, but I'll add the project name in
> the "bag of tags" in the subject lines.
> 
> The QEMU series introduces two extensions to the ALLOCATE firmware
> linker/loader command.
> 
> One extension is a new allocation zone, with value 3, for allowing the
> firmware to allocate the fw_cfg blobs in 64-bit address space.

Seems to make sense. I guess it's safe to do this if no
pointers to this table are 32 bit, right?
Is there a chance we'll ever be able to use this on PC
assuming the need to support 32 bit guests?

> The other extension is a repurposing of the most significant bit (bit 7)
> in the zone field. This bit becomes orthogonal to the rest of the zone
> field. If the bit is set, it means that QEMU promises the firmware that
> the blob referenced by the ALLOCATE command contains no ACPI tables at all.

This one is a bit strange in that it does not seem to be about
allocations - it seems to be about content.

I'd like to better understand what makes ACPI special.

I see two other things that make acpi special, but I'd like to make sure
1. I think that RSDT from qemu is more or less ignored by OVMF, it
   builds it from tables supplied. Thus pointers from RSDT only serve to
   find beginning of tables - they are not really patched in. So ACPI
   tables are special in that their actual addresses are unused. As a
   result they can be moved at will after linker runs.
2. Some tables can go into AddressRangeACPI, some into AddressRangeNVS,
   but they never need to be in AddressRangeReserved.
   It would be simple if we could just say "allocate this table
   from AddressRangeACPI". But I am not sure this is true
   since e.g. stuff used for power management can't go into
   AddressRangeACPI.  Thoughts?


> After introducing these, the QEMU series puts them to use, covering all
> of the currently generated ALLOCATE commands, as appropriate. Among the
> benefits we can mention
> - the removal of the OVMF ACPI SDT Header Probe suppressor from VMGENID
> (and from any similar future devices),
> - and the fact that the "virt" machine type (and maybe other machine
> types) of the arm/aarch64 target will no longer require RAM under 4GB
> for ACPI to work.
> 
> Both of these extensions are irrelevant for SeaBIOS, therefore the
> SeaBIOS patches simply mask out bit 7 (for ignoring the "no ACPI
> content" hint), and fall back to the HIGH zone (= 32-bit address space)
> when the 64-bit zone is permitted.
> 
> In other words, SeaBIOS needs some patches to recognize the new zone
> values, but beyond that, the behavior is unchanged.
> 
> Both extensions are important for virtual UEFI firmware (OVMF in x86
> guests and ArmVirtQemu in aarch64 guests). The edk2 patches add support
> to OvmfPkg/AcpiPlatformDxe for the extensions. Please see the commit
> messages for details (all the extensions are explained in detail in the
> relevant patches for all of the projects).
> 
> The patches can cause linker/loader breakage when old firmware is booted
> on new QEMU. However, that's no problem (it's nothing new), the next
> release of QEMU should bundle the new firmware binaries as always.
> 
> New firmware will continue running on old QEMU without issues.
> 
> (In case you have sent me emails about this in the last few tens of
> hours, please know that I'm not ignoring them, I just haven't seen /
> read them. Reading emails every five minutes makes focused work
> impossible, so when I'm busy, I tend to read email once per day.)
> 
> Thanks
> Laszlo