Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support

[Paolo Bonzini]

On 26/07/2017 15:08, Igor Mammedov wrote:
> On Tue, 25 Jul 2017 18:23:22 +0200
> Paolo Bonzini <address@hidden> wrote:
> 
>> On 25/07/2017 18:14, Laszlo Ersek wrote:
>>>   "No regressions became apparent in tests with a range of Windows
>>>    (XP-10)"
>>>
>>> In theory, w2k falls within that range.  
>>
>> Nope, Windows 2000 is like NT 5.0, XP is like NT 5.1. :(
>>
>> One possibility is to fix it in SeaBIOS instead: if you get a 2.0 FADT
>> and an XSDT and no RSDT, it can build an RSDT and a 1.0 FADT itself,
>> patching the RSDT to point to it.
>>
>> It's a hack, but it's the only place I see to make it "just work".  And
>> it could be extended nicely in the future.
>>
>> All QEMU would have to do is to provide an XSDT _instead_ of an RSDT.
> I'd support it, however it would break migrated guests with old BIOS
> image in RAM on reboot.

Why?  Shouldn't the old ACPI tables get migrated together with the old
BIOS?  Or are they rebuilt after reset?

Paolo

> Legacy users have an option to build SeaBIOS without ACPI from QEMU
> support by turning off CONFIG_FW_ROMFILE_LOAD (or use old SeaBIOS)
> which leads to using legacy tables included in SeaBIOS.
> Then mgmt layer above libvirt which knows what guest OS it's
> going to run can pick legacy BIOS image for it.
> 
> But the testing issue will still stay as normally it's not tested
> path.
> 
> PS:
> For now we are going to revert PC machine to rev1 and leave q35 at rev3
> as Michael suggested to keep both w2k and macos happy.
> 
>>
>> Paolo
>>
>>> In practice, it is impossible to
>>> test *all* Windows versions against ACPI generator changes, even if you
>>> try to be thorough (which Phil was). One might not even *know about*
>>> "all" Windows versions. So people using w2k and similar should
>>> co-maintain the ACPI stuff and report back with testing on the fly;
>>> otherwise regressions are impossible to avoid.  
>>
>