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