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
