On 26/07/2017 15:08, Igor Mammedov wrote: > On Tue, 25 Jul 2017 18:23:22 +0200 > Paolo Bonzini <[email protected]> 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. >> >
