Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
On 08/06/2017 19:44, Michael S. Tsirkin wrote: > On Tue, Jun 06, 2017 at 08:10:17PM +0200, Laszlo Ersek wrote: >> On 06/05/17 18:02, Michael S. Tsirkin wrote: >>> On Sat, Jun 03, 2017 at 09:36:23AM +0200, Laszlo Ersek wrote: On 06/02/17 17:45, Laszlo Ersek wrote: > 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. Dave made a good point (which I should have realized myself, really!), namely if you launch old fw on old qemu, then migrate the guest to a new qemu and then reboot the guest on the target host, within the migrated VM, things will break. So that makes this approach dead in the water. Possible mitigations I could think of: - Make it machine type dependent. Complicated (we don't usually bind ACPI generation to machine types) and wouldn't help existing devices. - Let the firmware negotiate these extensions. Very complicated (new fw-cfg files are needed for negotiation) and wouldn't help existing devices. >>> >>> This last option *shouldn't* be complicated. If it is something's wrong. >>> >>> Maybe we made a mistake when we added etc/smi/*features*. >>> >>> It's not too late to move these to etc/*features* for new >>> machine types if we want to and if you can do the firmware >>> work. Then you'd just take out a bit and be done with it. >>> >>> I don't insist on doing the ACPI thing now but I do think >>> infrastructure for negotiating extensions should be there. >> >> Different drivers in the firmware would need to negotiate different >> questions / features with QEMU independently of each other. The "thing" >> in OVMF that negotiates (and uses) the SMI broadcast is very-very >> different and separate from the "thing" in OVMF that handles the ACPI >> linker/loader script. > > They both could call a common library. > > Also, we don't need separate fw cfg files - we could > reserve ranges of bits in a single file. > E.g. bits 0-31 - smi, 32-63 - tseg, etc. TSEG size is an integer, not a boolean... Paolo
Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
On Tue, Jun 06, 2017 at 08:10:17PM +0200, Laszlo Ersek wrote: > On 06/05/17 18:02, Michael S. Tsirkin wrote: > > On Sat, Jun 03, 2017 at 09:36:23AM +0200, Laszlo Ersek wrote: > >> On 06/02/17 17:45, Laszlo Ersek wrote: > >> > >>> 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. > >> > >> Dave made a good point (which I should have realized myself, really!), > >> namely if you launch old fw on old qemu, then migrate the guest to a new > >> qemu and then reboot the guest on the target host, within the migrated > >> VM, things will break. > >> > >> So that makes this approach dead in the water. > >> > >> Possible mitigations I could think of: > >> - Make it machine type dependent. Complicated (we don't usually bind > >> ACPI generation to machine types) and wouldn't help existing devices. > >> - Let the firmware negotiate these extensions. Very complicated (new > >> fw-cfg files are needed for negotiation) and wouldn't help existing > >> devices. > > > > This last option *shouldn't* be complicated. If it is something's wrong. > > > > Maybe we made a mistake when we added etc/smi/*features*. > > > > It's not too late to move these to etc/*features* for new > > machine types if we want to and if you can do the firmware > > work. Then you'd just take out a bit and be done with it. > > > > I don't insist on doing the ACPI thing now but I do think > > infrastructure for negotiating extensions should be there. > > Different drivers in the firmware would need to negotiate different > questions / features with QEMU independently of each other. The "thing" > in OVMF that negotiates (and uses) the SMI broadcast is very-very > different and separate from the "thing" in OVMF that handles the ACPI > linker/loader script. They both could call a common library. Also, we don't need separate fw cfg files - we could reserve ranges of bits in a single file. E.g. bits 0-31 - smi, 32-63 - tseg, etc. -- MST
Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
On 06/05/17 18:02, Michael S. Tsirkin wrote: > On Sat, Jun 03, 2017 at 09:36:23AM +0200, Laszlo Ersek wrote: >> On 06/02/17 17:45, Laszlo Ersek wrote: >> >>> 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. >> >> Dave made a good point (which I should have realized myself, really!), >> namely if you launch old fw on old qemu, then migrate the guest to a new >> qemu and then reboot the guest on the target host, within the migrated >> VM, things will break. >> >> So that makes this approach dead in the water. >> >> Possible mitigations I could think of: >> - Make it machine type dependent. Complicated (we don't usually bind >> ACPI generation to machine types) and wouldn't help existing devices. >> - Let the firmware negotiate these extensions. Very complicated (new >> fw-cfg files are needed for negotiation) and wouldn't help existing devices. > > This last option *shouldn't* be complicated. If it is something's wrong. > > Maybe we made a mistake when we added etc/smi/*features*. > > It's not too late to move these to etc/*features* for new > machine types if we want to and if you can do the firmware > work. Then you'd just take out a bit and be done with it. > > I don't insist on doing the ACPI thing now but I do think > infrastructure for negotiating extensions should be there. Different drivers in the firmware would need to negotiate different questions / features with QEMU independently of each other. The "thing" in OVMF that negotiates (and uses) the SMI broadcast is very-very different and separate from the "thing" in OVMF that handles the ACPI linker/loader script. As one example, the first "thing" mentioned above is not even built into ArmVirtQemu (only into OVMF, i.e. x86), while the second "thing" is built into both aarch64 and x86 firmware. So, I think we couldn't share the same fw_cfg files (if they needed write access & lock-down too, i.e. actual negotiation from the firmware) between wildly unrelated features. The virtio feature negotiation is different because each device gets its own negotiation, and that maps very well to UEFI concepts too. BTW, do we have a specific concern relating to the number of fw_cfg files? That count can now be raised from machine type to machine type, but Paolo didn't seem to like raising the current value (or maybe I misunderstood him): http://mid.mail-archive.com/2e6dec37-8b69-979b-c856-406233273066@redhat.com ... Also, above I wrote, with regard to feature negotiation, that it "wouldn't help existing devices". By that I mean this: Consider the NOACPI content hint as an example. If the firmware doesn't negotiate it (before selecting and downloading the ACPI payload), then QEMU cannot generate the NOACPI content hint. In turn QEMU must keep the OVMF SDT Header Probe suppressor (those paddings and AML additions) enabled. But, for the QEMU developers it means that the suppressor code has to be kept around forever, for compatibility with old machine types. And if you do that, then why add a negotiable NOACPI hint at all? That would just further complicate device code (because now you have to generate two different AML payloads), where the old one (the one with the explicit suppressor) would work just fine "forever". Thanks, Laszlo
Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
On 06/05/17 11:54, Igor Mammedov wrote: > BTW: > how OVMF would deal with booting 32-bit OS if it would allocate > ACPI tables above 4Gb? > For BIOS on baremetal I'd expect some switch in settings, something > like "Disable 32-bit OS support". In order to answer your question exhaustively, I'd have to ponder this a lot longer. For now my basic answer is the following: - If you can allocate memory above 4GB in the DXE phase, that means your DXE and BDS phases are 64-bit. Which in turn implies you *cannot* boot a 32-bit OS at all. Generally speaking, with PI / UEFI, the bitness of the firmware (the DXE and the BDS phases) and the bitness of the OS (incl. its UEFI boot loader) must be identical. As a trick, Linux can work around this, in *one* direction -- 64-bit Linux can run on 32-bit UEFI firmware (on x86; not sure about other arches). But, the other direction (32-bit UEFI OS on 64-bit firmware) cannot work, minimally because you can only call the UEFI runtime services in 64-bit mode. In short (again, this is quite rudimentary), if your memory allocation in the DXE and/or BDS phases ends up being served from above 4GB, you won't be booting a 32-bit-only OS. Thanks Laszlo
Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
On Sat, Jun 03, 2017 at 09:36:23AM +0200, Laszlo Ersek wrote: > On 06/02/17 17:45, Laszlo Ersek wrote: > > > 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. > > Dave made a good point (which I should have realized myself, really!), > namely if you launch old fw on old qemu, then migrate the guest to a new > qemu and then reboot the guest on the target host, within the migrated > VM, things will break. > > So that makes this approach dead in the water. > > Possible mitigations I could think of: > - Make it machine type dependent. Complicated (we don't usually bind > ACPI generation to machine types) and wouldn't help existing devices. > - Let the firmware negotiate these extensions. Very complicated (new > fw-cfg files are needed for negotiation) and wouldn't help existing devices. This last option *shouldn't* be complicated. If it is something's wrong. Maybe we made a mistake when we added etc/smi/*features*. It's not too late to move these to etc/*features* for new machine types if we want to and if you can do the firmware work. Then you'd just take out a bit and be done with it. I don't insist on doing the ACPI thing now but I do think infrastructure for negotiating extensions should be there. -- MST
Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
On Sat, 3 Jun 2017 09:36:23 +0200 Laszlo Ersek wrote: > On 06/02/17 17:45, Laszlo Ersek wrote: > > > 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. > > Dave made a good point (which I should have realized myself, really!), > namely if you launch old fw on old qemu, then migrate the guest to a new > qemu and then reboot the guest on the target host, within the migrated > VM, things will break. [...] > Regarding the NOACPI hint, I guess I'm dropping that. I only meant > NOACPI for addressing Igor's long-standing dislike for the "ACPI SDT > header probe suppression" in VMGENID (and future similar devices). But, > there's no actual *technical* need to eliminate that I'd consider eliminating wasting space technical need, but there are not a lot of tables that need it so far and implementing NOACPI hint would lead to all out compat logic impl. along with it (either negotiation or machine versioning). The later seem to me too much so I wouldn't bother with it yet. > (unlike the technical need for 64-bit blob allocations which should really be > solved) here I disagree, having 32bit pointer is sufficient enough hint. Yep, firmware have to scan linker script to determine limits before doing allocations but it's totally upto firmware to decide where to allocate tables. It also helps to avoid in qemu 2 points where we'd have to specify that table is "64 bit-able" in add_pointer and allocate. BTW: how OVMF would deal with booting 32-bit OS if it would allocate ACPI tables above 4Gb? For BIOS on baremetal I'd expect some switch in settings, something like "Disable 32-bit OS support". > Self-nack for this set of sets. > > Thanks for the feedback, > Laszlo >
Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
* Laszlo Ersek (ler...@redhat.com) wrote: > On 06/02/17 17:45, Laszlo Ersek wrote: > > > 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. > > Dave made a good point (which I should have realized myself, really!), > namely if you launch old fw on old qemu, then migrate the guest to a new > qemu and then reboot the guest on the target host, within the migrated > VM, things will break. Yep, sorry it always complicates things; as does the opposite case of back-migrating a VM with an old machine type but newer bios to an old qemu. Dave > So that makes this approach dead in the water. > > Possible mitigations I could think of: > - Make it machine type dependent. Complicated (we don't usually bind > ACPI generation to machine types) and wouldn't help existing devices. > - Let the firmware negotiate these extensions. Very complicated (new > fw-cfg files are needed for negotiation) and wouldn't help existing devices. > > So I guess I'll do what Igor and Gerd suggested: record in advance > whether any pointer field narrower than 8 bytes points into a given > blob, and if so, forbid allocating that blob from 64-bit address space. > This should solve Ard's needs purely within the firmware. > > Regarding the NOACPI hint, I guess I'm dropping that. I only meant > NOACPI for addressing Igor's long-standing dislike for the "ACPI SDT > header probe suppression" in VMGENID (and future similar devices). But, > there's no actual *technical* need to eliminate that (unlike the > technical need for 64-bit blob allocations which should really be > solved), so I guess it's OK to postpone NOACPI indefinitely. > > Self-nack for this set of sets. > > Thanks for the feedback, > Laszlo -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
On 06/02/2017 07:20 PM, Laszlo Ersek wrote: On 06/02/17 18:30, Michael S. Tsirkin wrote: 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? That's right. For example, the TCPA patch (6 of 7) in the QEMU series does this, because the ACPI_BUILD_TPMLOG_FILE is only referenced by a 64-bit pointer. Is there a chance we'll ever be able to use this on PC assuming the need to support 32 bit guests? Well, sticking with the TCPA example, if an ACPI table defines *only* an 8-byte pointer to some memory area, that seems to preclude support for 32-bit guests already, generally speaking, no? I just tested this, giving 8G of memory to a VM and running i386 Fedora in it. The memory allocated for the TCPA log seems to be in 32bit memory, so not out of reach of i386 guests. I guess it's important what the firmware does with it, whether it strictly follows the 64bit and allocates memory as far up as possible or provides compatibility. SeaBIOS (1.10.0) seems to do the right thing. Stefan
Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
On 06/02/17 17:45, Laszlo Ersek wrote: > 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. Dave made a good point (which I should have realized myself, really!), namely if you launch old fw on old qemu, then migrate the guest to a new qemu and then reboot the guest on the target host, within the migrated VM, things will break. So that makes this approach dead in the water. Possible mitigations I could think of: - Make it machine type dependent. Complicated (we don't usually bind ACPI generation to machine types) and wouldn't help existing devices. - Let the firmware negotiate these extensions. Very complicated (new fw-cfg files are needed for negotiation) and wouldn't help existing devices. So I guess I'll do what Igor and Gerd suggested: record in advance whether any pointer field narrower than 8 bytes points into a given blob, and if so, forbid allocating that blob from 64-bit address space. This should solve Ard's needs purely within the firmware. Regarding the NOACPI hint, I guess I'm dropping that. I only meant NOACPI for addressing Igor's long-standing dislike for the "ACPI SDT header probe suppression" in VMGENID (and future similar devices). But, there's no actual *technical* need to eliminate that (unlike the technical need for 64-bit blob allocations which should really be solved), so I guess it's OK to postpone NOACPI indefinitely. Self-nack for this set of sets. Thanks for the feedback, Laszlo
Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
On 06/02/17 18:30, Michael S. Tsirkin wrote: > 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? That's right. For example, the TCPA patch (6 of 7) in the QEMU series does this, because the ACPI_BUILD_TPMLOG_FILE is only referenced by a 64-bit pointer. > Is there a chance we'll ever be able to use this on PC > assuming the need to support 32 bit guests? Well, sticking with the TCPA example, if an ACPI table defines *only* an 8-byte pointer to some memory area, that seems to preclude support for 32-bit guests already, generally speaking, no? But otherwise I agree, requiring support for 32-bit guests makes this allocation zone a lot less useful. >> 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. Sure, I only stuffed it in the Zone field because that's where I found a free bit :) > > 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. Sort of. OVMF performs two passes on the linker/loader script. The first pass is fully identical to what SeaBIOS does, so the RSDT too is allocated (as part of its containing fw_cfg blob, of course) and its fields are patched like anything else. In the second pass, the (now relocated) pointers are checked again, based on the ADD_POINTER commands. Wherever the (now relocated) pointers point, we probe for ACPI table headers. If the target passes the probe (i.e., it looks like an ACPI table), we call EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() with it. This installs a separate copy of that table, maintaining RSDT and XSDT internally. Now, the RSD PTR table has a pointer to the RSDT, so normally we'd invoke InstallAcpiTable() with the RSDT as well, in the second pass. To prevent that, we have a quirk that recognizes RSDT and XSDT, and skips them. So you can say that the RSDT from QEMU is *ultimately* ignored in OVMF, but for the first pass to complete (which is identical to SeaBIOS's only pass), OVMF uses the RSDT (as embedded in its containing fw_cfg blob) too. There are more details about the second pass. If a (relocated) pointer points to some stuff that doesn't look like an ACPI table header, then we don't install that thing with InstallAcpiTable(). Instead, we think that at that location the containing fw_cfg blob contains an opregion-like area, so its actual absolute address is relevant (remember we are past the first pass, which completed all the relocations). So in this case, the containing fw_cfg blob is marked as "non-releasable", and we'll keep it forever (in AcpiNVS memory). Otherwise, if at the end of processing a blob is marked as releasable (the default), because all pointers into it pointed only at ACPI table headers, we free the blob. There are more details about the second pass. There can be several pointers that point to the same address (= same offset of the same pointed-to fw_cfg blob). In such cases, only the first encounter is honored with an InstallAcpiTable() call, further surfacings of the same target address are skipped. Now, the heuristics to determine whether a pointed-to location is an ACPI table header or not, is not fool-proof. It recognizes all valid headers (so no false negatives), I think, but it could also mis-recognize random garbage in an opregion-like blob as an ACPI table header (so there's a chance for false positives). In order to suppress these false positives deterministically, there are two methods: - prefix all such areas in the pointed-to blobs with a sufficient number of zeroes so that the probe would fail, guaranteed. However, this means that you have to keep the ADD_POINTER commands pointed at the zeroes, not at the rea
Re: [Qemu-devel] allocation zone extensions for the firmware linker/loader
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
[Qemu-devel] allocation zone extensions for the firmware linker/loader
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. 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. 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
