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