Re: allocation zone extensions for the firmware linker/loader

[Paolo Bonzini <pbonzini@redhat.com>]

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