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

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

[Programmingkid]

I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:

commit 77af8a2b95b79699de650965d5228772743efe84
Author: Phil Dennis-Jordan <phil@philjordan.eu>
Date:   Wed Mar 15 19:20:26 2017 +1300

    hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.
    
    This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register.
    
    The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions.
    
    The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content.
    
    Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
    Message-Id: <1489558827-28971-2-git-send-email-phil@philjordan.eu>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

:040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M	hw
:040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M	include
:040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M	tests

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

[Phil Dennis-Jordan]

On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
<programmingkidx@gmail.com> wrote:
> I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:

Ouch. I reckon we have 2 options for fixing this:

1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
to be pointed to by an XSDT, which Qemu currently doesn't implement at
all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
this? Any likely other OS regressions?

2. Select FADT version with an option. This one is definitely safe,
but adds yet another option.

Thoughts?


> commit 77af8a2b95b79699de650965d5228772743efe84
> Author: Phil Dennis-Jordan <phil@philjordan.eu>
> Date:   Wed Mar 15 19:20:26 2017 +1300
>
>     hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.
>
>     This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register.
>
>     The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions.
>
>     The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content.
>
>     Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
>     Message-Id: <1489558827-28971-2-git-send-email-phil@philjordan.eu>
>     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>
> :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M      hw
> :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M      include
> :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M      tests
>
>

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

[Programmingkid]

> On Jul 20, 2017, at 3:29 PM, Phil Dennis-Jordan <lists@philjordan.eu> wrote:
> 
> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
> <programmingkidx@gmail.com> wrote:
>> I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
> 
> Ouch. I reckon we have 2 options for fixing this:
> 
> 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
> to be pointed to by an XSDT, which Qemu currently doesn't implement at
> all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
> this? Any likely other OS regressions?
> 
> 2. Select FADT version with an option. This one is definitely safe,
> but adds yet another option.
> 
> Thoughts?

Option 1 sounds good to me. 

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

[Igor Mammedov]

On Thu, 20 Jul 2017 21:29:33 +0200
Phil Dennis-Jordan <lists@philjordan.eu> wrote:

> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
> <programmingkidx@gmail.com> wrote:
> > I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
w2k is very ancient (and long time EOLed), I can't even download it from msdn to test
(oldest available is XP)

do we really care about it?

 
> Ouch. I reckon we have 2 options for fixing this:
> 
> 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
> to be pointed to by an XSDT, which Qemu currently doesn't implement at
> all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
> this? Any likely other OS regressions?
> 
> 2. Select FADT version with an option. This one is definitely safe,
> but adds yet another option.
the 3rd simpler option is:
  force rev1 on old machine types (2.9 and older),
  using machine compat machinery and use rev3 on newer machines


> 
> Thoughts?
> 
> 
> > commit 77af8a2b95b79699de650965d5228772743efe84
> > Author: Phil Dennis-Jordan <phil@philjordan.eu>
> > Date:   Wed Mar 15 19:20:26 2017 +1300
> >
> >     hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.
> >
> >     This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register.
> >
> >     The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions.
> >
> >     The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content.
> >
> >     Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
> >     Message-Id: <1489558827-28971-2-git-send-email-phil@philjordan.eu>
> >     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> >
> > :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M      hw
> > :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M      include
> > :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M      tests
> >
> >  
> 

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

[Phil Dennis-Jordan]

On Fri, Jul 21, 2017 at 11:06 AM, Igor Mammedov <imammedo@redhat.com> wrote:
> On Thu, 20 Jul 2017 21:29:33 +0200
> Phil Dennis-Jordan <lists@philjordan.eu> wrote:
>
>> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
>> <programmingkidx@gmail.com> wrote:
>> > I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
> w2k is very ancient (and long time EOLed), I can't even download it from msdn to test
> (oldest available is XP)
>
> do we really care about it?

I guess it'd primarily be for software archival/history purposes,
which is a reasonable use case for Qemu. (See efforts to get PPC MacOS
working, etc.)

>> Ouch. I reckon we have 2 options for fixing this:
>>
>> 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
>> to be pointed to by an XSDT, which Qemu currently doesn't implement at
>> all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
>> this? Any likely other OS regressions?
>>
>> 2. Select FADT version with an option. This one is definitely safe,
>> but adds yet another option.
> the 3rd simpler option is:
>   force rev1 on old machine types (2.9 and older),
>   using machine compat machinery and use rev3 on newer machines

That sounds good, I'd be happy to implement that.

Phil

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

[Daniel P. Berrange]

On Thu, Jul 20, 2017 at 09:29:33PM +0200, Phil Dennis-Jordan wrote:
> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
> <programmingkidx@gmail.com> wrote:
> > I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
> 
> Ouch. I reckon we have 2 options for fixing this:
> 
> 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
> to be pointed to by an XSDT, which Qemu currently doesn't implement at
> all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
> this? Any likely other OS regressions?
> 
> 2. Select FADT version with an option. This one is definitely safe,
> but adds yet another option.
> 
> Thoughts?

The original comit below claims the change does not impact guest ABI
compatibility, so do we understand why Windows broke ?

If the commit message was inaccurate, and *does* in fact change ABI,
then we should have added an option to toggle FADT version, and used
machine type versioning to ensure we didn't regress existing machine
types. IOW option 2.

That would still, however, leave Windows 2k broken on new machine
types which is pretty poor experiance, but is probably all that
we have time for in the current freeze period.

If we can do option 1 in the 2.11 release that would potentially
give better user experiance by not being broken out of the box
with the latest machine type.


> > commit 77af8a2b95b79699de650965d5228772743efe84
> > Author: Phil Dennis-Jordan <phil@philjordan.eu>
> > Date:   Wed Mar 15 19:20:26 2017 +1300
> >
> >     hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.
> >
> >     This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register.
> >
> >     The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions.
> >
> >     The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content.
> >
> >     Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
> >     Message-Id: <1489558827-28971-2-git-send-email-phil@philjordan.eu>
> >     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> >
> > :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M      hw
> > :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M      include
> > :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M      tests
> >
> >
> 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Daniel P. Berrange]

On Fri, Jul 21, 2017 at 11:06:36AM +0200, Igor Mammedov wrote:
> On Thu, 20 Jul 2017 21:29:33 +0200
> Phil Dennis-Jordan <lists@philjordan.eu> wrote:
> 
> > On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
> > <programmingkidx@gmail.com> wrote:
> > > I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
> w2k is very ancient (and long time EOLed), I can't even download it from msdn to test
> (oldest available is XP)
> 
> do we really care about it?

>From a Red Hat, we don't care about it, because we're only targetting
modern OS in RHEL, but from a QEMU community POV ability to run pretty
much any guest OS you care to find is definitely in scope.

> > Ouch. I reckon we have 2 options for fixing this:
> > 
> > 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
> > to be pointed to by an XSDT, which Qemu currently doesn't implement at
> > all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
> > this? Any likely other OS regressions?
> > 
> > 2. Select FADT version with an option. This one is definitely safe,
> > but adds yet another option.
> the 3rd simpler option is:
>   force rev1 on old machine types (2.9 and older),
>   using machine compat machinery and use rev3 on newer machines

That's not really a 3rd option - it is something that applies to
both option 1 and 2.

The original commit, and both these options involve changes are
sensitive to guest ABI. So all machine types from 2.9 and earlier
*must* be configured to stick with the ACPI 1.0 FADT only.

Whether we then have an option to turn on ACPI 2.0, or instead
expose 1.0 and 2.0 at the same time, both must only happen on
the 2.10 machine type (or newer if it misses this release).


> > > commit 77af8a2b95b79699de650965d5228772743efe84
> > > Author: Phil Dennis-Jordan <phil@philjordan.eu>
> > > Date:   Wed Mar 15 19:20:26 2017 +1300
> > >
> > >     hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.
> > >
> > >     This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register.
> > >
> > >     The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions.
> > >
> > >     The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content.
> > >
> > >     Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
> > >     Message-Id: <1489558827-28971-2-git-send-email-phil@philjordan.eu>
> > >     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > >
> > > :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M      hw
> > > :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M      include
> > > :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M      tests
> > >
> > >  
> > 
> 
> 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Igor Mammedov]

On Fri, 21 Jul 2017 10:20:26 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Thu, Jul 20, 2017 at 09:29:33PM +0200, Phil Dennis-Jordan wrote:
> > On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
> > <programmingkidx@gmail.com> wrote:  
> > > I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:  
> > 
> > Ouch. I reckon we have 2 options for fixing this:
> > 
> > 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
> > to be pointed to by an XSDT, which Qemu currently doesn't implement at
> > all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
> > this? Any likely other OS regressions?
> > 
> > 2. Select FADT version with an option. This one is definitely safe,
> > but adds yet another option.
> > 
> > Thoughts?  
> 
> The original comit below claims the change does not impact guest ABI
> compatibility, so do we understand why Windows broke ?
Author made a reasonable effort to test with variety of guest OSes upto
vanilla WinXP, we can't blame ourselves for not testing OS that's is not
available.

Well we don't know why w2k breaks, only that it bisects to this commit.
 

> 
> If the commit message was inaccurate, and *does* in fact change ABI,
> then we should have added an option to toggle FADT version, and used
> machine type versioning to ensure we didn't regress existing machine
> types. IOW option 2.
> 
> That would still, however, leave Windows 2k broken on new machine
> types which is pretty poor experiance, but is probably all that
> we have time for in the current freeze period.
> 
> If we can do option 1 in the 2.11 release that would potentially
> give better user experiance by not being broken out of the box
> with the latest machine type.
option 1 might confuse/break OVMF.

I've just posted patch to unconditionally force rev1 for pc-i440fx-2.9
and older machines, while q35 and newer pc would use rev3.

> 
> 
> > > commit 77af8a2b95b79699de650965d5228772743efe84
> > > Author: Phil Dennis-Jordan <phil@philjordan.eu>
> > > Date:   Wed Mar 15 19:20:26 2017 +1300
> > >
> > >     hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.
> > >
> > >     This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register.
> > >
> > >     The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions.
> > >
> > >     The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content.
> > >
> > >     Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
> > >     Message-Id: <1489558827-28971-2-git-send-email-phil@philjordan.eu>
> > >     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > >
> > > :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M      hw
> > > :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M      include
> > > :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M      tests
> > >
> > >  
> >   
> 
> Regards,
> Daniel

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

[Phil Dennis-Jordan]

On Fri, Jul 21, 2017 at 11:46 AM, Igor Mammedov <imammedo@redhat.com> wrote:
> On Fri, 21 Jul 2017 10:20:26 +0100
> "Daniel P. Berrange" <berrange@redhat.com> wrote:
>
>> On Thu, Jul 20, 2017 at 09:29:33PM +0200, Phil Dennis-Jordan wrote:
>> > On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
>> > <programmingkidx@gmail.com> wrote:
>> > > I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
>> >
>> > Ouch. I reckon we have 2 options for fixing this:
>> >
>> > 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
>> > to be pointed to by an XSDT, which Qemu currently doesn't implement at
>> > all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
>> > this? Any likely other OS regressions?
>> >
>> > 2. Select FADT version with an option. This one is definitely safe,
>> > but adds yet another option.
>> >
>> > Thoughts?
>>
>> The original comit below claims the change does not impact guest ABI
>> compatibility, so do we understand why Windows broke ?
> Author made a reasonable effort to test with variety of guest OSes upto
> vanilla WinXP, we can't blame ourselves for not testing OS that's is not
> available.
>
> Well we don't know why w2k breaks, only that it bisects to this commit.

Short of having access to Win2K source or reverse engineering, we can
only guess - but it's almost certainly got to be one or more of these:

1. It can't handle FADT revision != 1 (as opposed to later systems
which evidently test for >= 1)
2. It can't handle if FADT length != sizeof(ACPI 1.0 FADT) (again, as
opposed to testing for >=)
3. It only computes the checksum over the hardcoded ACPI 1.0 FADT
length, not over the number of bytes in the length field.

There isn't a way to reconcile these with a valid ACPI 2.0 FADT.

I've found these presentation slides from Intel's IDF 2001:
http://www.acpi.info/presentations/S01USMOBS169_OS%20new.ppt
On slide 10, "ACPI 2.0 System Description Tables (Windows 2000
Compatibility)" it indicates that two FADTs are required for Win2k,
with the RSDT pointing to an ACPI 1.0 FADT, and the XSDT pointing to a
2.0 one. (This is my "option 1")

Presumably this is how shipping Win2K-compatible hardware implemented
it, so I'd expect FOSS operating systems to be able to deal with this
kind of setup too. Moreover, the ACPI 2.0 spec says (5.2.7) "An ACPI
2.0-compatible OS must use the XSDT if present." which also suggests
that the RSDT should be ignored if the OS can handle the XSDT. Whether
ALL proprietary OSes can deal with it in practice is another question.

>> If the commit message was inaccurate, and *does* in fact change ABI,
>> then we should have added an option to toggle FADT version, and used
>> machine type versioning to ensure we didn't regress existing machine
>> types. IOW option 2.
>>
>> That would still, however, leave Windows 2k broken on new machine
>> types which is pretty poor experiance, but is probably all that
>> we have time for in the current freeze period.
>>
>> If we can do option 1 in the 2.11 release that would potentially
>> give better user experiance by not being broken out of the box
>> with the latest machine type.
> option 1 might confuse/break OVMF.
>
> I've just posted patch to unconditionally force rev1 for pc-i440fx-2.9
> and older machines, while q35 and newer pc would use rev3.
>
>>
>>
>> > > commit 77af8a2b95b79699de650965d5228772743efe84
>> > > Author: Phil Dennis-Jordan <phil@philjordan.eu>
>> > > Date:   Wed Mar 15 19:20:26 2017 +1300
>> > >
>> > >     hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.
>> > >
>> > >     This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register.
>> > >
>> > >     The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions.
>> > >
>> > >     The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content.
>> > >
>> > >     Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
>> > >     Message-Id: <1489558827-28971-2-git-send-email-phil@philjordan.eu>
>> > >     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> > >
>> > > :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M      hw
>> > > :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M      include
>> > > :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M      tests
>> > >
>> > >
>> >
>>
>> Regards,
>> Daniel
>

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

[BALATON Zoltan]

On Fri, 21 Jul 2017, Igor Mammedov wrote:
> On Fri, 21 Jul 2017 10:20:26 +0100
> "Daniel P. Berrange" <berrange@redhat.com> wrote:
>> On Thu, Jul 20, 2017 at 09:29:33PM +0200, Phil Dennis-Jordan wrote:
>>> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
>>> <programmingkidx@gmail.com> wrote:
>>>> I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
>>>
>>> Ouch. I reckon we have 2 options for fixing this:
>>>
>>> 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
>>> to be pointed to by an XSDT, which Qemu currently doesn't implement at
>>> all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
>>> this? Any likely other OS regressions?
>>>
>>> 2. Select FADT version with an option. This one is definitely safe,
>>> but adds yet another option.
>>>
>>> Thoughts?
>>
>> The original comit below claims the change does not impact guest ABI
>> compatibility, so do we understand why Windows broke ?
> Author made a reasonable effort to test with variety of guest OSes upto
> vanilla WinXP, we can't blame ourselves for not testing OS that's is not
> available.
>
> Well we don't know why w2k breaks, only that it bisects to this commit.

I don't know if this helps but I've found that this same commit also broke 
booting OS X on q35 with OVMF and Clover (some old versions I had and 
worked before this commit). See here:
http://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04306.html

Maybe it's simpler to debug as these are open source but it's still not 
very clear why they fail because it starts to boot OS X but hangs during 
kernel init (and maybe Win2K fails to boot because of something else). I 
think I've seen this with OVMF 58f025afd and Clover 3354 (or around that, 
not completely sure about these versions).

Regards,
BALATON Zoltan

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

[Phil Dennis-Jordan]

On Fri, Jul 21, 2017 at 12:50 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
> On Fri, 21 Jul 2017, Igor Mammedov wrote:
>>
>> On Fri, 21 Jul 2017 10:20:26 +0100
>> "Daniel P. Berrange" <berrange@redhat.com> wrote:
>>>
>>> On Thu, Jul 20, 2017 at 09:29:33PM +0200, Phil Dennis-Jordan wrote:
>>>>
>>>> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
>>>> <programmingkidx@gmail.com> wrote:
>>>>>
>>>>> I noticed that Windows 2000 does not boot up in QEMU recently. After
>>>>> bisecting the issue I found the offending commit:
>>>>
>>>>
>>>> Ouch. I reckon we have 2 options for fixing this:
>>>>
>>>> 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
>>>> to be pointed to by an XSDT, which Qemu currently doesn't implement at
>>>> all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
>>>> this? Any likely other OS regressions?
>>>>
>>>> 2. Select FADT version with an option. This one is definitely safe,
>>>> but adds yet another option.
>>>>
>>>> Thoughts?
>>>
>>>
>>> The original comit below claims the change does not impact guest ABI
>>> compatibility, so do we understand why Windows broke ?
>>
>> Author made a reasonable effort to test with variety of guest OSes upto
>> vanilla WinXP, we can't blame ourselves for not testing OS that's is not
>> available.
>>
>> Well we don't know why w2k breaks, only that it bisects to this commit.
>
>
> I don't know if this helps but I've found that this same commit also broke
> booting OS X on q35 with OVMF and Clover (some old versions I had and worked
> before this commit). See here:
> http://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04306.html
>
> Maybe it's simpler to debug as these are open source but it's still not very
> clear why they fail because it starts to boot OS X but hangs during kernel
> init (and maybe Win2K fails to boot because of something else). I think I've
> seen this with OVMF 58f025afd and Clover 3354 (or around that, not
> completely sure about these versions).

OVMF had 2 bugs that totally mucked up the ACPI tables if Qemu didn't
supply its loader commands "just so", and modified ACPI 2.0-5.0 FADTs
in such a way that they were no longer valid. These are fixed in
198a46d and 072060a, which are about a year newer than 58f025afd, so
it's no surprise this combination doesn't work. I have no idea if
Clover on top makes any difference.

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

[Igor Mammedov]

On Fri, 21 Jul 2017 10:23:38 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Fri, Jul 21, 2017 at 11:06:36AM +0200, Igor Mammedov wrote:
> > On Thu, 20 Jul 2017 21:29:33 +0200
> > Phil Dennis-Jordan <lists@philjordan.eu> wrote:
> >   
> > > On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
> > > <programmingkidx@gmail.com> wrote:  
> > > > I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:  
> > w2k is very ancient (and long time EOLed), I can't even download it from msdn to test
> > (oldest available is XP)
> > 
> > do we really care about it?  
> 
> From a Red Hat, we don't care about it, because we're only targetting
> modern OS in RHEL, but from a QEMU community POV ability to run pretty
> much any guest OS you care to find is definitely in scope.
As far as someone is willing to maintain it and test it regularly,
otherwise it will beak someday anyway.
(I'm not really willing to do it as I don't have access to w2k and
interested in reducing maintainable code, but maybe someone would
like to step up, feel free to post patch to amend acpi maintaners)

currently option 1 looks like the most compatible approach
but there is no way to predict if it will break some other OS
and it is not trivial to implement and maintain.

CCing Laszlo, to get his opinion if option 1 is viable from
old/new OVMF standpoint (is it possible in 2.10 time frame?).


> > > Ouch. I reckon we have 2 options for fixing this:
> > > 
> > > 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
> > > to be pointed to by an XSDT, which Qemu currently doesn't implement at
> > > all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
> > > this? Any likely other OS regressions?
> > > 
> > > 2. Select FADT version with an option. This one is definitely safe,
> > > but adds yet another option.  
> > the 3rd simpler option is:
> >   force rev1 on old machine types (2.9 and older),
> >   using machine compat machinery and use rev3 on newer machines  
> 
> That's not really a 3rd option - it is something that applies to
> both option 1 and 2.
> 
> The original commit, and both these options involve changes are
> sensitive to guest ABI. So all machine types from 2.9 and earlier
> *must* be configured to stick with the ACPI 1.0 FADT only.
It's not per se ABI change, ABI is still the same but BIOS
supplied ACPI tables changed (nowdays they are generated by QEMU)
to new ones. Currently QEMU does not support versioned firmware,
i.e. each new release ships updated firmware and old machines
also use it. The same typically applies to ACPI tables.

Alternative workaround, for w2k user (management), doesn't even
requires any fixes to qemu, he/she should just use old enough bios
with new QEMU (bios from 1.7 or 1.6 should work as it doesn't fetch
ACPI tables from QEMU).

Another alternative is just keep just using old QEMU version with w2k,
the sources are available.
If user's figured out that he/she needs to force FADT(rev1) for w2k
not to crash (he is either able to bisect/compile QEMU or read this
thread at which point he/she should be able to his poison i.e.
compiling vs old bios)


> Whether we then have an option to turn on ACPI 2.0, or instead
> expose 1.0 and 2.0 at the same time, both must only happen on
> the 2.10 machine type (or newer if it misses this release).
> 
> 
> > > > commit 77af8a2b95b79699de650965d5228772743efe84
> > > > Author: Phil Dennis-Jordan <phil@philjordan.eu>
> > > > Date:   Wed Mar 15 19:20:26 2017 +1300
> > > >
> > > >     hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.
> > > >
> > > >     This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register.
> > > >
> > > >     The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions.
> > > >
> > > >     The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content.
> > > >
> > > >     Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
> > > >     Message-Id: <1489558827-28971-2-git-send-email-phil@philjordan.eu>
> > > >     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > > >
> > > > :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M      hw
> > > > :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M      include
> > > > :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M      tests
> > > >
> > > >    
> > >   
> > 
> >   
> 
> Regards,
> Daniel

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

[BALATON Zoltan]

On Fri, 21 Jul 2017, Phil Dennis-Jordan wrote:
> On Fri, Jul 21, 2017 at 12:50 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> I don't know if this helps but I've found that this same commit also broke
>> booting OS X on q35 with OVMF and Clover (some old versions I had and worked
>> before this commit). See here:
>> http://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg04306.html
>>
>> Maybe it's simpler to debug as these are open source but it's still not very
>> clear why they fail because it starts to boot OS X but hangs during kernel
>> init (and maybe Win2K fails to boot because of something else). I think I've
>> seen this with OVMF 58f025afd and Clover 3354 (or around that, not
>> completely sure about these versions).
>
> OVMF had 2 bugs that totally mucked up the ACPI tables if Qemu didn't
> supply its loader commands "just so", and modified ACPI 2.0-5.0 FADTs
> in such a way that they were no longer valid. These are fixed in
> 198a46d and 072060a, which are about a year newer than 58f025afd, so
> it's no surprise this combination doesn't work. I have no idea if
> Clover on top makes any difference.

I've tried with 072060a and with that version OS X boots with same Clover 
so my problem seems to have been too old OVMF version and Clover does not 
make a difference here. So this also likely has nothing do with the Win2k 
problem discussed in this thread so you can disregard my post.

Thank you,
BALATON Zoltan

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

[Phil Dennis-Jordan]

On Fri, Jul 21, 2017 at 2:34 PM, Igor Mammedov <imammedo@redhat.com> wrote:
> On Fri, 21 Jul 2017 10:23:38 +0100
> "Daniel P. Berrange" <berrange@redhat.com> wrote:
>
>> On Fri, Jul 21, 2017 at 11:06:36AM +0200, Igor Mammedov wrote:
>> > On Thu, 20 Jul 2017 21:29:33 +0200
>> > Phil Dennis-Jordan <lists@philjordan.eu> wrote:
>> >
>> > > On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
>> > > <programmingkidx@gmail.com> wrote:
>> > > > I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
>> > w2k is very ancient (and long time EOLed), I can't even download it from msdn to test
>> > (oldest available is XP)
>> >
>> > do we really care about it?
>>
>> From a Red Hat, we don't care about it, because we're only targetting
>> modern OS in RHEL, but from a QEMU community POV ability to run pretty
>> much any guest OS you care to find is definitely in scope.
> As far as someone is willing to maintain it and test it regularly,
> otherwise it will beak someday anyway.
> (I'm not really willing to do it as I don't have access to w2k and
> interested in reducing maintainable code, but maybe someone would
> like to step up, feel free to post patch to amend acpi maintaners)
>
> currently option 1 looks like the most compatible approach
> but there is no way to predict if it will break some other OS
> and it is not trivial to implement and maintain.
>
> CCing Laszlo, to get his opinion if option 1 is viable from
> old/new OVMF standpoint (is it possible in 2.10 time frame?).

I've not done a deep investigation yet, but I've put together a really
quick prototype for the split RSDT/XSDT with 2 FADTs. I tested my
existing WinXP x86, Win10 x64, and Ubuntu 16.04 x86-64 test images
with SeaBIOS and they all worked.

With OVMF, neither Windows 10 nor macOS would boot with this change -
I don't currently know if that's OVMF's fault or if my prototype is
broken. I don't have time right now to dig deeper into this, but
hopefully I can look at it on Monday and also dig out a Win2000 disc
then as well and test with that.

The prototype patch is at https://github.com/pmj/qemu/tree/xsdt right
now for anyone curious, or with more time on their hands to test it
with Win2K and figure out why it's not working with OVMF. I'll try to
do a proper RFC patch submission on Monday once I have a better handle
on what's going on.

I don't have any strong release policy opinions - I'll leave that to
those with more experience. I'd be disappointed though if we had to
entirely revert the Rev3 FADT patch for 2.10.

>> > > Ouch. I reckon we have 2 options for fixing this:
>> > >
>> > > 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
>> > > to be pointed to by an XSDT, which Qemu currently doesn't implement at
>> > > all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
>> > > this? Any likely other OS regressions?
>> > >
>> > > 2. Select FADT version with an option. This one is definitely safe,
>> > > but adds yet another option.
>> > the 3rd simpler option is:
>> >   force rev1 on old machine types (2.9 and older),
>> >   using machine compat machinery and use rev3 on newer machines
>>
>> That's not really a 3rd option - it is something that applies to
>> both option 1 and 2.
>>
>> The original commit, and both these options involve changes are
>> sensitive to guest ABI. So all machine types from 2.9 and earlier
>> *must* be configured to stick with the ACPI 1.0 FADT only.
> It's not per se ABI change, ABI is still the same but BIOS
> supplied ACPI tables changed (nowdays they are generated by QEMU)
> to new ones. Currently QEMU does not support versioned firmware,
> i.e. each new release ships updated firmware and old machines
> also use it. The same typically applies to ACPI tables.
>
> Alternative workaround, for w2k user (management), doesn't even
> requires any fixes to qemu, he/she should just use old enough bios
> with new QEMU (bios from 1.7 or 1.6 should work as it doesn't fetch
> ACPI tables from QEMU).
>
> Another alternative is just keep just using old QEMU version with w2k,
> the sources are available.
> If user's figured out that he/she needs to force FADT(rev1) for w2k
> not to crash (he is either able to bisect/compile QEMU or read this
> thread at which point he/she should be able to his poison i.e.
> compiling vs old bios)
>
>
>> Whether we then have an option to turn on ACPI 2.0, or instead
>> expose 1.0 and 2.0 at the same time, both must only happen on
>> the 2.10 machine type (or newer if it misses this release).
>>
>>
>> > > > commit 77af8a2b95b79699de650965d5228772743efe84
>> > > > Author: Phil Dennis-Jordan <phil@philjordan.eu>
>> > > > Date:   Wed Mar 15 19:20:26 2017 +1300
>> > > >
>> > > >     hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.
>> > > >
>> > > >     This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register.
>> > > >
>> > > >     The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions.
>> > > >
>> > > >     The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content.
>> > > >
>> > > >     Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
>> > > >     Message-Id: <1489558827-28971-2-git-send-email-phil@philjordan.eu>
>> > > >     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> > > >
>> > > > :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M      hw
>> > > > :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M      include
>> > > > :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M      tests
>> > > >
>> > > >
>> > >
>> >
>> >
>>
>> Regards,
>> Daniel
>

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

[Gerd Hoffmann]

  Hi,

> > 2. Select FADT version with an option. This one is definitely safe,
> > but adds yet another option.
> 
> the 3rd simpler option is:
>   force rev1 on old machine types (2.9 and older),
>   using machine compat machinery and use rev3 on newer machines

How about keeping rev1 for pc machine type and use rev3 on q35 only?

Old guests which might fall over new acpi stuff usually work better
with "pc" anyway ...

cheers,
  Gerd

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

[John Snow]

On 07/21/2017 05:06 AM, Igor Mammedov wrote:
> On Thu, 20 Jul 2017 21:29:33 +0200
> Phil Dennis-Jordan <lists@philjordan.eu> wrote:
> 
>> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
>> <programmingkidx@gmail.com> wrote:
>>> I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
> w2k is very ancient (and long time EOLed), I can't even download it from msdn to test
> (oldest available is XP)
> 
> do we really care about it?
> 

Red Hat: "No, not really."
FOSS: "Yes, of course!"

Half the fun of QEMU (see also: QEMU Advent Calendar) is running old 
software. Technology moves so fast that even software from just 17 years 
ago is becoming impossible to run.

For historical and archival purposes it is absolutely of interest to be 
able to run one of Microsoft's most popular operating systems.

Of course, it's not particularly high on anyone's list who is getting 
paid to tend to QEMU, of course.

--js

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

[Programmingkid]

> On Jul 24, 2017, at 12:43 PM, John Snow <jsnow@redhat.com> wrote:
> 
> 
> 
> On 07/21/2017 05:06 AM, Igor Mammedov wrote:
>> On Thu, 20 Jul 2017 21:29:33 +0200
>> Phil Dennis-Jordan <lists@philjordan.eu> wrote:
>>> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
>>> <programmingkidx@gmail.com> wrote:
>>>> I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
>> w2k is very ancient (and long time EOLed), I can't even download it from msdn to test
>> (oldest available is XP)
>> do we really care about it?
> 
> Red Hat: "No, not really."
> FOSS: "Yes, of course!"
> 
> Half the fun of QEMU (see also: QEMU Advent Calendar) is running old software. Technology moves so fast that even software from just 17 years ago is becoming impossible to run.
> 
> For historical and archival purposes it is absolutely of interest to be able to run one of Microsoft's most popular operating systems.
> 
> Of course, it's not particularly high on anyone's list who is getting paid to tend to QEMU, of course.
> 
> —js

Well said.

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

[Laszlo Ersek]

On 07/21/17 20:29, Phil Dennis-Jordan wrote:
> On Fri, Jul 21, 2017 at 2:34 PM, Igor Mammedov <imammedo@redhat.com> wrote:
>> On Fri, 21 Jul 2017 10:23:38 +0100
>> "Daniel P. Berrange" <berrange@redhat.com> wrote:
>>
>>> On Fri, Jul 21, 2017 at 11:06:36AM +0200, Igor Mammedov wrote:
>>>> On Thu, 20 Jul 2017 21:29:33 +0200
>>>> Phil Dennis-Jordan <lists@philjordan.eu> wrote:
>>>>
>>>>> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
>>>>> <programmingkidx@gmail.com> wrote:
>>>>>> I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
>>>> w2k is very ancient (and long time EOLed), I can't even download it from msdn to test
>>>> (oldest available is XP)
>>>>
>>>> do we really care about it?
>>>
>>> From a Red Hat, we don't care about it, because we're only targetting
>>> modern OS in RHEL, but from a QEMU community POV ability to run pretty
>>> much any guest OS you care to find is definitely in scope.
>> As far as someone is willing to maintain it and test it regularly,
>> otherwise it will beak someday anyway.
>> (I'm not really willing to do it as I don't have access to w2k and
>> interested in reducing maintainable code, but maybe someone would
>> like to step up, feel free to post patch to amend acpi maintaners)
>>
>> currently option 1 looks like the most compatible approach
>> but there is no way to predict if it will break some other OS
>> and it is not trivial to implement and maintain.
>>
>> CCing Laszlo, to get his opinion if option 1 is viable from
>> old/new OVMF standpoint (is it possible in 2.10 time frame?).
> 
> I've not done a deep investigation yet, but I've put together a really
> quick prototype for the split RSDT/XSDT with 2 FADTs. I tested my
> existing WinXP x86, Win10 x64, and Ubuntu 16.04 x86-64 test images
> with SeaBIOS and they all worked.
> 
> With OVMF, neither Windows 10 nor macOS would boot with this change -
> I don't currently know if that's OVMF's fault or if my prototype is
> broken. I don't have time right now to dig deeper into this, but
> hopefully I can look at it on Monday and also dig out a Win2000 disc
> then as well and test with that.

Thanks for the CC.

With edk2 you cannot install one FADT that is pointed-to by an RSDT
entry and another FADT that is pointed-to by an XSDT entry.

- The two FADT versions are at separate places in guest memory, so the
multiply-pointed-to table handling that we collaborated on last time
does not apply (justifiedly -- these are separate tables, not a single
table being the target of multiple pointers).

- This means that both FADT versions will be passed to
InstallAcpiTable(). The implementation in
"MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c" handles
both RSDT and XSDT entries automatically (there's no way for OVMF to say
"I want this one linked into RSDT, and that one linked into XSDT"), so
the firstly installed FADT is linked into both root tables, and the
secondly installed FADT is rejected with EFI_ACCESS_DENIED.

- The failure in turn causes OVMF to roll back all the ACPI
linker/loader processing done thus far, and to fall back to the built-in
(very ancient) default tables. It's not surprising that modern OSes
don't boot with those tables.

So approach (1) cannot work with UEFI.

I could imagine approach (2) like this:

- continue with unversioned firmware
- introduce a master switch called "ancient ACPI" vs. "modern ACPI"
- tie this knob to machine types
- factor the "ancient ACPI" stuff out to a separate set of source files
- assign additional maintainers (like Igor suggests) to the "ancient
  ACPI" source files.

I agree with Igor 100% that the "ancient ACPI" stuff has to be
maintained by people that *actually use* OSes that require ancient ACPI.
In commit 77af8a2b95b7 ("hw/i386: Use Rev3 FADT (ACPI 2.0) instead of
Rev1 to improve guest OS support.", 2017-03-15), Phil wrote

  "No regressions became apparent in tests with a range of Windows
   (XP-10)"

In theory, w2k falls within that range. 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.

(Continuous integration covering *all* Windows versions is impossible
for obvious reasons ($$$).)

Thanks
Laszlo

> 
> The prototype patch is at https://github.com/pmj/qemu/tree/xsdt right
> now for anyone curious, or with more time on their hands to test it
> with Win2K and figure out why it's not working with OVMF. I'll try to
> do a proper RFC patch submission on Monday once I have a better handle
> on what's going on.
> 
> I don't have any strong release policy opinions - I'll leave that to
> those with more experience. I'd be disappointed though if we had to
> entirely revert the Rev3 FADT patch for 2.10.
> 
>>>>> Ouch. I reckon we have 2 options for fixing this:
>>>>>
>>>>> 1. Export two FADTs, one ACPI 1.0, one ACPI 2.0. The latter would need
>>>>> to be pointed to by an XSDT, which Qemu currently doesn't implement at
>>>>> all as far as I'm aware. Any ideas on how SeaBIOS or OVMF would handle
>>>>> this? Any likely other OS regressions?
>>>>>
>>>>> 2. Select FADT version with an option. This one is definitely safe,
>>>>> but adds yet another option.
>>>> the 3rd simpler option is:
>>>>   force rev1 on old machine types (2.9 and older),
>>>>   using machine compat machinery and use rev3 on newer machines
>>>
>>> That's not really a 3rd option - it is something that applies to
>>> both option 1 and 2.
>>>
>>> The original commit, and both these options involve changes are
>>> sensitive to guest ABI. So all machine types from 2.9 and earlier
>>> *must* be configured to stick with the ACPI 1.0 FADT only.
>> It's not per se ABI change, ABI is still the same but BIOS
>> supplied ACPI tables changed (nowdays they are generated by QEMU)
>> to new ones. Currently QEMU does not support versioned firmware,
>> i.e. each new release ships updated firmware and old machines
>> also use it. The same typically applies to ACPI tables.
>>
>> Alternative workaround, for w2k user (management), doesn't even
>> requires any fixes to qemu, he/she should just use old enough bios
>> with new QEMU (bios from 1.7 or 1.6 should work as it doesn't fetch
>> ACPI tables from QEMU).
>>
>> Another alternative is just keep just using old QEMU version with w2k,
>> the sources are available.
>> If user's figured out that he/she needs to force FADT(rev1) for w2k
>> not to crash (he is either able to bisect/compile QEMU or read this
>> thread at which point he/she should be able to his poison i.e.
>> compiling vs old bios)
>>
>>
>>> Whether we then have an option to turn on ACPI 2.0, or instead
>>> expose 1.0 and 2.0 at the same time, both must only happen on
>>> the 2.10 machine type (or newer if it misses this release).
>>>
>>>
>>>>>> commit 77af8a2b95b79699de650965d5228772743efe84
>>>>>> Author: Phil Dennis-Jordan <phil@philjordan.eu>
>>>>>> Date:   Wed Mar 15 19:20:26 2017 +1300
>>>>>>
>>>>>>     hw/i386: Use Rev3 FADT (ACPI 2.0) instead of Rev1 to improve guest OS support.
>>>>>>
>>>>>>     This updates the FADT generated for x86/64 machine types from Revision 1 to 3. (Based on ACPI standard 2.0 instead of 1.0) The intention is to expose the reset register information to guest operating systems which require it, specifically OS X/macOS. Revision 1 FADTs do not contain the fields relating to the reset register.
>>>>>>
>>>>>>     The new layout and contents remains backwards-compatible with operating systems which only support ACPI 1.0, as the existing fields are not modified by this change, as the 64-bit and 32-bit variants are allowed to co-exist according to the ACPI 2.0 standard. No regressions became apparent in tests with a range of Windows (XP-10) and Linux versions.
>>>>>>
>>>>>>     The BIOS tables test suite's FADT checksum test has also been updated to reflect the new FADT layout and content.
>>>>>>
>>>>>>     Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
>>>>>>     Message-Id: <1489558827-28971-2-git-send-email-phil@philjordan.eu>
>>>>>>     Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>>>>>>
>>>>>> :040000 040000 40063761c0b86f87e798e03ea48eff9ea0753425 6d2a94150cf1eafb16f0ccf6325281415fef64a6 M      hw
>>>>>> :040000 040000 fe3f1480a91b76fea238c765f0725e715932d96d 68f9368d8d78fd3267f609b603f97e8a74bdf528 M      include
>>>>>> :040000 040000 895e961b0a160100aa95b2f557cfe6b87a7d9bff 8ed08cef10fddee7814e38ad62be11371592a75a M      tests
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>> Regards,
>>> Daniel
>>

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

[Paolo Bonzini]

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.

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.

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

[Paolo Bonzini]

On 25/07/2017 18:23, Paolo Bonzini 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.

Completely untested code follows.  Machine type compatibility code 
should not be necessary because new QEMU always starts with a new BIOS.

Not sure I'll have much time for this in the next few days, so help
is appreciated.

Paolo

QEMU:

diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
index 36a6cc450e..ea750d54d9 100644
--- a/hw/acpi/aml-build.c
+++ b/hw/acpi/aml-build.c
@@ -1573,33 +1573,6 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre)
     g_array_free(tables->vmgenid, mfre);
 }
 
-/* Build rsdt table */
-void
-build_rsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,
-           const char *oem_id, const char *oem_table_id)
-{
-    int i;
-    unsigned rsdt_entries_offset;
-    AcpiRsdtDescriptorRev1 *rsdt;
-    const unsigned table_data_len = (sizeof(uint32_t) * table_offsets->len);
-    const unsigned rsdt_entry_size = sizeof(rsdt->table_offset_entry[0]);
-    const size_t rsdt_len = sizeof(*rsdt) + table_data_len;
-
-    rsdt = acpi_data_push(table_data, rsdt_len);
-    rsdt_entries_offset = (char *)rsdt->table_offset_entry - table_data->data;
-    for (i = 0; i < table_offsets->len; ++i) {
-        uint32_t ref_tbl_offset = g_array_index(table_offsets, uint32_t, i);
-        uint32_t rsdt_entry_offset = rsdt_entries_offset + rsdt_entry_size * i;
-
-        /* rsdt->table_offset_entry to be filled by Guest linker */
-        bios_linker_loader_add_pointer(linker,
-            ACPI_BUILD_TABLE_FILE, rsdt_entry_offset, rsdt_entry_size,
-            ACPI_BUILD_TABLE_FILE, ref_tbl_offset);
-    }
-    build_header(linker, table_data,
-                 (void *)rsdt, "RSDT", rsdt_len, 1, oem_id, oem_table_id);
-}
-
 /* Build xsdt table */
 void
 build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 6b7bade183..ad00f6affd 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2557,12 +2557,12 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker)
 }
 
 static GArray *
-build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned rsdt_tbl_offset)
+build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset)
 {
     AcpiRsdpDescriptor *rsdp = acpi_data_push(rsdp_table, sizeof *rsdp);
-    unsigned rsdt_pa_size = sizeof(rsdp->rsdt_physical_address);
-    unsigned rsdt_pa_offset =
-        (char *)&rsdp->rsdt_physical_address - rsdp_table->data;
+    unsigned xsdt_pa_size = sizeof(rsdp->xsdt_physical_address);
+    unsigned xsdt_pa_offset =
+        (char *)&rsdp->xsdt_physical_address - rsdp_table->data;
 
     bios_linker_loader_alloc(linker, ACPI_BUILD_RSDP_FILE, rsdp_table, 16,
                              true /* fseg memory */);
@@ -2571,8 +2571,8 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned rsdt_tbl_offset)
     memcpy(rsdp->oem_id, ACPI_BUILD_APPNAME6, 6);
     /* Address to be filled by Guest linker */
     bios_linker_loader_add_pointer(linker,
-        ACPI_BUILD_RSDP_FILE, rsdt_pa_offset, rsdt_pa_size,
-        ACPI_BUILD_TABLE_FILE, rsdt_tbl_offset);
+        ACPI_BUILD_RSDP_FILE, xsdt_pa_offset, xsdt_pa_size,
+        ACPI_BUILD_TABLE_FILE, xsdt_tbl_offset);
 
     /* Checksum to be filled by Guest linker */
     bios_linker_loader_add_checksum(linker, ACPI_BUILD_RSDP_FILE,
@@ -2621,7 +2621,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
     PCMachineState *pcms = PC_MACHINE(machine);
     PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
     GArray *table_offsets;
-    unsigned facs, dsdt, rsdt, fadt;
+    unsigned facs, dsdt, xsdt, fadt;
     AcpiPmInfo pm;
     AcpiMiscInfo misc;
     AcpiMcfgInfo mcfg;
@@ -2730,12 +2730,12 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
     }
 
     /* RSDT is pointed to by RSDP */
-    rsdt = tables_blob->len;
-    build_rsdt(tables_blob, tables->linker, table_offsets,
+    xsdt = tables_blob->len;
+    build_xsdt(tables_blob, tables->linker, table_offsets,
                slic_oem.id, slic_oem.table_id);
 
     /* RSDP is in FSEG memory, so allocate it separately */
-    build_rsdp(tables->rsdp, tables->linker, rsdt);
+    build_rsdp(tables->rsdp, tables->linker, xsdt);
 
     /* We'll expose it all to Guest so we want to reduce
      * chance of size changes.


SeaBIOS:

>From 73b0facdb7349f5dbf24dc675647b68eeeec0ff4 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Tue, 25 Jul 2017 18:50:19 +0200
Subject: [PATCH 1/2] seabios: build RSDT from XSDT

Old operating systems would like to have a v1 FADT, but new
operating systems would like to have v3.

Since old operating systems do not know about XSDTs, the
solution is to point the RSDT to a v1 FADT and the XSDT to a
v3 FADT.

But, OVMF is not able to do that and barfs when it sees the
second FADT---plus really it's only BIOS operating systems
such as win2k that complain.  So instead: 1) make QEMU provide
an XSDT only; 2) build the RSDT and v1 FADT in SeaBIOS.

This patch makes SeaBIOS build an RSDT out of an existing XSDT.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 src/fw/paravirt.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
 src/std/acpi.h    | 11 +++++++++++
 2 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index 5b23d78..19a4abe 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -25,6 +25,7 @@
 #include "x86.h" // cpuid
 #include "xen.h" // xen_biostable_setup
 #include "stacks.h" // yield
+#include "std/acpi.h"
 
 // Amount of continuous ram under 4Gig
 u32 RamSize;
@@ -147,6 +148,46 @@ static void msr_feature_control_setup(void)
         wrmsr_smp(MSR_IA32_FEATURE_CONTROL, feature_control_bits);
 }
 
+static void
+build_compatibility_rsdt(void)
+{
+    if (RsdpAddr->rsdt_physical_address)
+        return;
+
+    u64 xsdt_addr = RsdpAddr->xsdt_physical_address;
+    if (xsdt_addr & ~0xffffffffULL)
+        return;
+
+    struct xsdt_descriptor_rev1 *xsdt = (void*)(u32)xsdt_addr;
+    void *end = (void*)xsdt + xsdt->length;
+    struct rsdt_descriptor_rev1 *rsdt;
+    int rsdt_size = offsetof(struct rsdt_descriptor_rev1, table_offset_entry[0]);
+    int i;
+    for (i=0; (void*)&xsdt->table_offset_entry[i] < end; i++) {
+        u64 tbl_addr = xsdt->table_offset_entry[i];
+        if (!tbl_addr || (tbl_addr & ~0xffffffffULL))
+            continue;
+        rsdt_size += 4;
+    }
+
+    rsdt = malloc_high(rsdt_size);
+    RsdpAddr->rsdt_physical_address = (u32)rsdt;
+
+    memcpy(rsdt, xsdt, sizeof(struct acpi_table_header));
+    rsdt->signature = RSDT_SIGNATURE;
+    rsdt->length = rsdt_size;
+    rsdt->revision = 1;
+    int j;
+    for (i=j=0; (void*)&xsdt->table_offset_entry[i] < end; i++) {
+        u64 tbl_addr = xsdt->table_offset_entry[i];
+        if (!tbl_addr || (tbl_addr & ~0xffffffffULL))
+            continue;
+        rsdt->table_offset_entry[j++] = (u32)tbl_addr;
+    }
+
+    rsdt->checksum -= checksum(rsdt, rsdt_size);
+}
+
 void
 qemu_platform_setup(void)
 {
@@ -186,8 +227,10 @@ qemu_platform_setup(void)
 
         RsdpAddr = find_acpi_rsdp();
 
-        if (RsdpAddr)
+        if (RsdpAddr) {
+            build_compatibility_rsdt();
             return;
+        }
 
         /* If present, loader should have installed an RSDP.
          * Not installed? We might still be able to continue
diff --git a/src/std/acpi.h b/src/std/acpi.h
index c2ea707..caf5e7e 100644
--- a/src/std/acpi.h
+++ b/src/std/acpi.h
@@ -133,6 +133,17 @@ struct rsdt_descriptor_rev1
 } PACKED;
 
 /*
+ * ACPI 2.0 Root System Description Table (RSDT)
+ */
+#define XSDT_SIGNATURE 0x54445358 // RSDT
+struct xsdt_descriptor_rev1
+{
+    ACPI_TABLE_HEADER_DEF       /* ACPI common table header */
+    u64 table_offset_entry[0];  /* Array of pointers to other */
+    /* ACPI tables */
+} PACKED;
+
+/*
  * ACPI 1.0 Firmware ACPI Control Structure (FACS)
  */
 #define FACS_SIGNATURE 0x53434146 // FACS
-- 
2.13.3


>From 46c7a296d27bd487cfd89a40973b1e61426dfbd0 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Tue, 25 Jul 2017 18:59:20 +0200
Subject: [PATCH 2/2] seabios: create v1 FADT in compatibility RSDT

This patch presents a v1 FADT inside the compatibility RSDT, so
that old operating systems are not broken.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 src/fw/paravirt.c | 18 +++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
index 19a4abe..a9b9e80 100644
--- a/src/fw/paravirt.c
+++ b/src/fw/paravirt.c
@@ -148,6 +148,18 @@ static void msr_feature_control_setup(void)
         wrmsr_smp(MSR_IA32_FEATURE_CONTROL, feature_control_bits);
 }
 
+static void*
+build_rev1_fadt(struct fadt_descriptor_rev1 *fadt_v3)
+{
+    struct fadt_descriptor_rev1 *fadt_v1 = malloc_high(sizeof *fadt_v1);
+
+    memcpy(fadt_v1, fadt_v3, sizeof *fadt_v1);
+    fadt_v1->length = sizeof *fadt_v1;
+    fadt_v1->revision = 1;
+    fadt_v1->checksum -= checksum(fadt_v1, fadt_v1->length);
+    return fadt_v1;
+}
+
 static void
 build_compatibility_rsdt(void)
 {
@@ -182,6 +194,12 @@ build_compatibility_rsdt(void)
         u64 tbl_addr = xsdt->table_offset_entry[i];
         if (!tbl_addr || (tbl_addr & ~0xffffffffULL))
             continue;
+        struct acpi_table_header *tbl = (void*)(u32)tbl_addr;
+        /* The RSDT should only have an ACPI 1.0 FADT according to
+         * the spec.
+         */
+        if (tbl->signature == FACP_SIGNATURE && tbl->revision > 1)
+            tbl_addr = (u32)build_rev1_fadt((void *)tbl);
         rsdt->table_offset_entry[j++] = (u32)tbl_addr;
     }
 
-- 
2.13.3

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

[Phil Dennis-Jordan]

Thanks for this, Paolo. Very interesting idea.

I couldn't get things working initially, but with a few fixups on the
SeaBIOS side I can boot both legacy and modern OSes. See comments
inline below for details on changes required.

Successfully booted (only a brief test):
- Windows 2000
- Windows XP (32 bit)
- Windows 7 (32 bit)
- Windows 10 (64 bit, SeaBIOS)
- Windows 10 (64 bit, OVMF)
- macOS 10.12 (patched OVMF)

On Tue, Jul 25, 2017 at 7:10 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 25/07/2017 18:23, Paolo Bonzini 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.
>
> Completely untested code follows.  Machine type compatibility code
> should not be necessary because new QEMU always starts with a new BIOS.
>
> Not sure I'll have much time for this in the next few days, so help
> is appreciated.
>
> Paolo
>
> QEMU:
>
> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
> index 36a6cc450e..ea750d54d9 100644
> --- a/hw/acpi/aml-build.c
> +++ b/hw/acpi/aml-build.c
> @@ -1573,33 +1573,6 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre)
>      g_array_free(tables->vmgenid, mfre);
>  }
>
> -/* Build rsdt table */
> -void
> -build_rsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,
> -           const char *oem_id, const char *oem_table_id)
> -{
> -    int i;
> -    unsigned rsdt_entries_offset;
> -    AcpiRsdtDescriptorRev1 *rsdt;
> -    const unsigned table_data_len = (sizeof(uint32_t) * table_offsets->len);
> -    const unsigned rsdt_entry_size = sizeof(rsdt->table_offset_entry[0]);
> -    const size_t rsdt_len = sizeof(*rsdt) + table_data_len;
> -
> -    rsdt = acpi_data_push(table_data, rsdt_len);
> -    rsdt_entries_offset = (char *)rsdt->table_offset_entry - table_data->data;
> -    for (i = 0; i < table_offsets->len; ++i) {
> -        uint32_t ref_tbl_offset = g_array_index(table_offsets, uint32_t, i);
> -        uint32_t rsdt_entry_offset = rsdt_entries_offset + rsdt_entry_size * i;
> -
> -        /* rsdt->table_offset_entry to be filled by Guest linker */
> -        bios_linker_loader_add_pointer(linker,
> -            ACPI_BUILD_TABLE_FILE, rsdt_entry_offset, rsdt_entry_size,
> -            ACPI_BUILD_TABLE_FILE, ref_tbl_offset);
> -    }
> -    build_header(linker, table_data,
> -                 (void *)rsdt, "RSDT", rsdt_len, 1, oem_id, oem_table_id);
> -}
> -
>  /* Build xsdt table */
>  void
>  build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 6b7bade183..ad00f6affd 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -2557,12 +2557,12 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker)
>  }
>
>  static GArray *
> -build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned rsdt_tbl_offset)
> +build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset)
>  {
>      AcpiRsdpDescriptor *rsdp = acpi_data_push(rsdp_table, sizeof *rsdp);
> -    unsigned rsdt_pa_size = sizeof(rsdp->rsdt_physical_address);
> -    unsigned rsdt_pa_offset =
> -        (char *)&rsdp->rsdt_physical_address - rsdp_table->data;
> +    unsigned xsdt_pa_size = sizeof(rsdp->xsdt_physical_address);
> +    unsigned xsdt_pa_offset =
> +        (char *)&rsdp->xsdt_physical_address - rsdp_table->data;
>
>      bios_linker_loader_alloc(linker, ACPI_BUILD_RSDP_FILE, rsdp_table, 16,
>                               true /* fseg memory */);
> @@ -2571,8 +2571,8 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned rsdt_tbl_offset)
>      memcpy(rsdp->oem_id, ACPI_BUILD_APPNAME6, 6);
>      /* Address to be filled by Guest linker */
>      bios_linker_loader_add_pointer(linker,
> -        ACPI_BUILD_RSDP_FILE, rsdt_pa_offset, rsdt_pa_size,
> -        ACPI_BUILD_TABLE_FILE, rsdt_tbl_offset);
> +        ACPI_BUILD_RSDP_FILE, xsdt_pa_offset, xsdt_pa_size,
> +        ACPI_BUILD_TABLE_FILE, xsdt_tbl_offset);
>
>      /* Checksum to be filled by Guest linker */
>      bios_linker_loader_add_checksum(linker, ACPI_BUILD_RSDP_FILE,
> @@ -2621,7 +2621,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
>      PCMachineState *pcms = PC_MACHINE(machine);
>      PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
>      GArray *table_offsets;
> -    unsigned facs, dsdt, rsdt, fadt;
> +    unsigned facs, dsdt, xsdt, fadt;
>      AcpiPmInfo pm;
>      AcpiMiscInfo misc;
>      AcpiMcfgInfo mcfg;
> @@ -2730,12 +2730,12 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
>      }
>
>      /* RSDT is pointed to by RSDP */
> -    rsdt = tables_blob->len;
> -    build_rsdt(tables_blob, tables->linker, table_offsets,
> +    xsdt = tables_blob->len;
> +    build_xsdt(tables_blob, tables->linker, table_offsets,
>                 slic_oem.id, slic_oem.table_id);
>
>      /* RSDP is in FSEG memory, so allocate it separately */
> -    build_rsdp(tables->rsdp, tables->linker, rsdt);
> +    build_rsdp(tables->rsdp, tables->linker, xsdt);
>
>      /* We'll expose it all to Guest so we want to reduce
>       * chance of size changes.
>
>
> SeaBIOS:
>
> From 73b0facdb7349f5dbf24dc675647b68eeeec0ff4 Mon Sep 17 00:00:00 2001
> From: Paolo Bonzini <pbonzini@redhat.com>
> Date: Tue, 25 Jul 2017 18:50:19 +0200
> Subject: [PATCH 1/2] seabios: build RSDT from XSDT
>
> Old operating systems would like to have a v1 FADT, but new
> operating systems would like to have v3.
>
> Since old operating systems do not know about XSDTs, the
> solution is to point the RSDT to a v1 FADT and the XSDT to a
> v3 FADT.
>
> But, OVMF is not able to do that and barfs when it sees the
> second FADT---plus really it's only BIOS operating systems
> such as win2k that complain.  So instead: 1) make QEMU provide
> an XSDT only; 2) build the RSDT and v1 FADT in SeaBIOS.
>
> This patch makes SeaBIOS build an RSDT out of an existing XSDT.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  src/fw/paravirt.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
>  src/std/acpi.h    | 11 +++++++++++
>  2 files changed, 55 insertions(+), 1 deletion(-)
>
> diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
> index 5b23d78..19a4abe 100644
> --- a/src/fw/paravirt.c
> +++ b/src/fw/paravirt.c
> @@ -25,6 +25,7 @@
>  #include "x86.h" // cpuid
>  #include "xen.h" // xen_biostable_setup
>  #include "stacks.h" // yield
> +#include "std/acpi.h"
>
>  // Amount of continuous ram under 4Gig
>  u32 RamSize;
> @@ -147,6 +148,46 @@ static void msr_feature_control_setup(void)
>          wrmsr_smp(MSR_IA32_FEATURE_CONTROL, feature_control_bits);
>  }
>
> +static void
> +build_compatibility_rsdt(void)
> +{
> +    if (RsdpAddr->rsdt_physical_address)
> +        return;
> +
> +    u64 xsdt_addr = RsdpAddr->xsdt_physical_address;
> +    if (xsdt_addr & ~0xffffffffULL)
> +        return;
> +
> +    struct xsdt_descriptor_rev1 *xsdt = (void*)(u32)xsdt_addr;
> +    void *end = (void*)xsdt + xsdt->length;
> +    struct rsdt_descriptor_rev1 *rsdt;
> +    int rsdt_size = offsetof(struct rsdt_descriptor_rev1, table_offset_entry[0]);
> +    int i;
> +    for (i=0; (void*)&xsdt->table_offset_entry[i] < end; i++) {
> +        u64 tbl_addr = xsdt->table_offset_entry[i];
> +        if (!tbl_addr || (tbl_addr & ~0xffffffffULL))
> +            continue;
> +        rsdt_size += 4;
> +    }
> +
> +    rsdt = malloc_high(rsdt_size);
> +    RsdpAddr->rsdt_physical_address = (u32)rsdt;

Modifying the RSDP like this invalidates both its checksums, so they
need to be adjusted. Something like this:

    RsdpAddr->checksum -= checksum(RsdpAddr, offsetof(struct
rsdp_descriptor, length));
    RsdpAddr->extended_checksum -= checksum(RsdpAddr, sizeof(struct
rsdp_descriptor));

> +
> +    memcpy(rsdt, xsdt, sizeof(struct acpi_table_header));
> +    rsdt->signature = RSDT_SIGNATURE;
> +    rsdt->length = rsdt_size;
> +    rsdt->revision = 1;
> +    int j;
> +    for (i=j=0; (void*)&xsdt->table_offset_entry[i] < end; i++) {
> +        u64 tbl_addr = xsdt->table_offset_entry[i];
> +        if (!tbl_addr || (tbl_addr & ~0xffffffffULL))
> +            continue;
> +        rsdt->table_offset_entry[j++] = (u32)tbl_addr;
> +    }
> +
> +    rsdt->checksum -= checksum(rsdt, rsdt_size);
> +}
> +
>  void
>  qemu_platform_setup(void)
>  {
> @@ -186,8 +227,10 @@ qemu_platform_setup(void)
>
>          RsdpAddr = find_acpi_rsdp();
>
> -        if (RsdpAddr)
> +        if (RsdpAddr) {
> +            build_compatibility_rsdt();
>              return;
> +        }
>
>          /* If present, loader should have installed an RSDP.
>           * Not installed? We might still be able to continue
> diff --git a/src/std/acpi.h b/src/std/acpi.h
> index c2ea707..caf5e7e 100644
> --- a/src/std/acpi.h
> +++ b/src/std/acpi.h
> @@ -133,6 +133,17 @@ struct rsdt_descriptor_rev1
>  } PACKED;
>
>  /*
> + * ACPI 2.0 Root System Description Table (RSDT)
> + */

Comment should be "ACPI 2.0 Extended System Description Table (XSDT)"

> +#define XSDT_SIGNATURE 0x54445358 // RSDT

The signature is "XSDT", that works out to 0x58445358

> +struct xsdt_descriptor_rev1
> +{
> +    ACPI_TABLE_HEADER_DEF       /* ACPI common table header */
> +    u64 table_offset_entry[0];  /* Array of pointers to other */
> +    /* ACPI tables */
> +} PACKED;
> +
> +/*
>   * ACPI 1.0 Firmware ACPI Control Structure (FACS)
>   */
>  #define FACS_SIGNATURE 0x53434146 // FACS
> --
> 2.13.3
>
>
> From 46c7a296d27bd487cfd89a40973b1e61426dfbd0 Mon Sep 17 00:00:00 2001
> From: Paolo Bonzini <pbonzini@redhat.com>
> Date: Tue, 25 Jul 2017 18:59:20 +0200
> Subject: [PATCH 2/2] seabios: create v1 FADT in compatibility RSDT
>
> This patch presents a v1 FADT inside the compatibility RSDT, so
> that old operating systems are not broken.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  src/fw/paravirt.c | 18 +++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
> index 19a4abe..a9b9e80 100644
> --- a/src/fw/paravirt.c
> +++ b/src/fw/paravirt.c
> @@ -148,6 +148,18 @@ static void msr_feature_control_setup(void)
>          wrmsr_smp(MSR_IA32_FEATURE_CONTROL, feature_control_bits);
>  }
>
> +static void*
> +build_rev1_fadt(struct fadt_descriptor_rev1 *fadt_v3)
> +{
> +    struct fadt_descriptor_rev1 *fadt_v1 = malloc_high(sizeof *fadt_v1);
> +
> +    memcpy(fadt_v1, fadt_v3, sizeof *fadt_v1);
> +    fadt_v1->length = sizeof *fadt_v1;
> +    fadt_v1->revision = 1;

We should mask out the flags bits that are reserved in ACPI 1.0 as
they refer to fields not present in this revision's FADT. e.g.

    // upper 23 bits reserved in rev1 FADT
    fadt_v1->flags &= 0x1ff;


> +    fadt_v1->checksum -= checksum(fadt_v1, fadt_v1->length);
> +    return fadt_v1;
> +}
> +
>  static void
>  build_compatibility_rsdt(void)
>  {
> @@ -182,6 +194,12 @@ build_compatibility_rsdt(void)
>          u64 tbl_addr = xsdt->table_offset_entry[i];
>          if (!tbl_addr || (tbl_addr & ~0xffffffffULL))
>              continue;
> +        struct acpi_table_header *tbl = (void*)(u32)tbl_addr;
> +        /* The RSDT should only have an ACPI 1.0 FADT according to
> +         * the spec.
> +         */
> +        if (tbl->signature == FACP_SIGNATURE && tbl->revision > 1)
> +            tbl_addr = (u32)build_rev1_fadt((void *)tbl);
>          rsdt->table_offset_entry[j++] = (u32)tbl_addr;
>      }
>
> --
> 2.13.3
>
>

With these changes:

Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu>

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

[Kevin O'Connor]

On Tue, Jul 25, 2017 at 07:10:21PM +0200, Paolo Bonzini wrote:
> On 25/07/2017 18:23, Paolo Bonzini 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.

It's an impressive hack!

> > 
> > All QEMU would have to do is to provide an XSDT _instead_ of an RSDT.
[...]
> SeaBIOS:
> 
> From 73b0facdb7349f5dbf24dc675647b68eeeec0ff4 Mon Sep 17 00:00:00 2001
> From: Paolo Bonzini <pbonzini@redhat.com>
> Date: Tue, 25 Jul 2017 18:50:19 +0200
> Subject: [PATCH 1/2] seabios: build RSDT from XSDT
> 
> Old operating systems would like to have a v1 FADT, but new
> operating systems would like to have v3.
> 
> Since old operating systems do not know about XSDTs, the
> solution is to point the RSDT to a v1 FADT and the XSDT to a
> v3 FADT.
> 
> But, OVMF is not able to do that and barfs when it sees the
> second FADT---plus really it's only BIOS operating systems
> such as win2k that complain.  So instead: 1) make QEMU provide
> an XSDT only; 2) build the RSDT and v1 FADT in SeaBIOS.
> 
> This patch makes SeaBIOS build an RSDT out of an existing XSDT.

I'd really prefer not to have SeaBIOS go back to producing ACPI
tables.

As an alternative, how about some other possible hacks:

1 - ovmf filters out the extra tables that it barfs on.

2 - change ovmf to read the fw_cfg linker script
    'etc/table-loader-ovmf' instead of '/etc/table-loader' and change
    qemu to generate two linker scripts - one for seabios and one for
    ovmf.

3 - same as 2, but change seabios to use 'etc/table-loader-seabios'
    and leave ovmf unchanged.

4 - change seabios to read both the linker script 'etc/table-loader'
    _and_ some new linker script '/etc/table-loader-legacy'.  Have
    qemu introduce the RSDT/FADTv1 in the "legacy" linker script.

-Kevin

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

[Paolo Bonzini]

On 26/07/2017 00:01, Kevin O'Connor wrote:
> On Tue, Jul 25, 2017 at 07:10:21PM +0200, Paolo Bonzini wrote:
>> On 25/07/2017 18:23, Paolo Bonzini 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.
> 
> It's an impressive hack!
> 
>>>
>>> All QEMU would have to do is to provide an XSDT _instead_ of an RSDT.
> [...]
>> SeaBIOS:
>>
>> From 73b0facdb7349f5dbf24dc675647b68eeeec0ff4 Mon Sep 17 00:00:00 2001
>> From: Paolo Bonzini <pbonzini@redhat.com>
>> Date: Tue, 25 Jul 2017 18:50:19 +0200
>> Subject: [PATCH 1/2] seabios: build RSDT from XSDT
>>
>> Old operating systems would like to have a v1 FADT, but new
>> operating systems would like to have v3.
>>
>> Since old operating systems do not know about XSDTs, the
>> solution is to point the RSDT to a v1 FADT and the XSDT to a
>> v3 FADT.
>>
>> But, OVMF is not able to do that and barfs when it sees the
>> second FADT---plus really it's only BIOS operating systems
>> such as win2k that complain.  So instead: 1) make QEMU provide
>> an XSDT only; 2) build the RSDT and v1 FADT in SeaBIOS.
>>
>> This patch makes SeaBIOS build an RSDT out of an existing XSDT.
> 
> I'd really prefer not to have SeaBIOS go back to producing ACPI
> tables.

Me too, but this is different from SeaBIOS producing ACPI tables.
(Patched) QEMU produces entirely valid ACPI 2.0 tables, while SeaBIOS is
only producing compatibility glue for old OSes.  Compared to producing
ACPI tables, SeaBIOS needs no knowledge of the underlying hardware, only
of the limitations of those old OSes.  Responsibilities between QEMU and
SeaBIOS are nicely split.

> As an alternative, how about some other possible hacks:
> 
> 1 - ovmf filters out the extra tables that it barfs on.
> 
> 2 - change ovmf to read the fw_cfg linker script
>     'etc/table-loader-ovmf' instead of '/etc/table-loader' and change
>     qemu to generate two linker scripts - one for seabios and one for
>     ovmf.
> 
> 3 - same as 2, but change seabios to use 'etc/table-loader-seabios'
>     and leave ovmf unchanged.
> 
> 4 - change seabios to read both the linker script 'etc/table-loader'
>     _and_ some new linker script '/etc/table-loader-legacy'.  Have
>     qemu introduce the RSDT/FADTv1 in the "legacy" linker script.

(4) would be acceptable I guess.  However I think it's a bit worse
because fw-cfg files are a somewhat scarce resource.  The "legacy"
aspect is something that SeaBIOS is in the best position to address,
because it knows what OSes are running on it; QEMU instead only takes
care of describing the hardware.

Paolo

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

[Paolo Bonzini]

On 25/07/2017 23:25, Phil Dennis-Jordan wrote:
> Thanks for this, Paolo. Very interesting idea.
> 
> I couldn't get things working initially, but with a few fixups on the
> SeaBIOS side I can boot both legacy and modern OSes. See comments
> inline below for details on changes required.
> 
> Successfully booted (only a brief test):
> - Windows 2000
> - Windows XP (32 bit)
> - Windows 7 (32 bit)
> - Windows 10 (64 bit, SeaBIOS)
> - Windows 10 (64 bit, OVMF)
> - macOS 10.12 (patched OVMF)

Thanks Phil!  You unwittingly tested the compatibility path on all these
OSes, since my QEMU patch forgot to setup rsdp->length, rsdp->revision
and the extended checksum.  However, I've now tested Windows XP, Linux
w/SeaBIOS, Linux w/patched SeaBIOS and Linux w/OVMF.

I've now found out that edk2 contains similar logic.  It uses a PCD (a
compile-time flag essentially) to choose between ACPI >= 2.0 tables or
ACPI 1.0-compatible tables.  In the latter case, edk2 takes care of
producing a v1 FADT if needed (similar to this patch) and linking the
RSDT to it; otherwise it keeps whatever FADT was provided by platform
code and produces an XSDT.  So I'm promoting the SeaBIOS code from
"hack" to "right thing to do".  Though then I cannot brag about Kevin's
nice words, too bad. :)

Paolo

> On Tue, Jul 25, 2017 at 7:10 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> On 25/07/2017 18:23, Paolo Bonzini 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.
>>
>> Completely untested code follows.  Machine type compatibility code
>> should not be necessary because new QEMU always starts with a new BIOS.
>>
>> Not sure I'll have much time for this in the next few days, so help
>> is appreciated.
>>
>> Paolo
>>
>> QEMU:
>>
>> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
>> index 36a6cc450e..ea750d54d9 100644
>> --- a/hw/acpi/aml-build.c
>> +++ b/hw/acpi/aml-build.c
>> @@ -1573,33 +1573,6 @@ void acpi_build_tables_cleanup(AcpiBuildTables *tables, bool mfre)
>>      g_array_free(tables->vmgenid, mfre);
>>  }
>>
>> -/* Build rsdt table */
>> -void
>> -build_rsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,
>> -           const char *oem_id, const char *oem_table_id)
>> -{
>> -    int i;
>> -    unsigned rsdt_entries_offset;
>> -    AcpiRsdtDescriptorRev1 *rsdt;
>> -    const unsigned table_data_len = (sizeof(uint32_t) * table_offsets->len);
>> -    const unsigned rsdt_entry_size = sizeof(rsdt->table_offset_entry[0]);
>> -    const size_t rsdt_len = sizeof(*rsdt) + table_data_len;
>> -
>> -    rsdt = acpi_data_push(table_data, rsdt_len);
>> -    rsdt_entries_offset = (char *)rsdt->table_offset_entry - table_data->data;
>> -    for (i = 0; i < table_offsets->len; ++i) {
>> -        uint32_t ref_tbl_offset = g_array_index(table_offsets, uint32_t, i);
>> -        uint32_t rsdt_entry_offset = rsdt_entries_offset + rsdt_entry_size * i;
>> -
>> -        /* rsdt->table_offset_entry to be filled by Guest linker */
>> -        bios_linker_loader_add_pointer(linker,
>> -            ACPI_BUILD_TABLE_FILE, rsdt_entry_offset, rsdt_entry_size,
>> -            ACPI_BUILD_TABLE_FILE, ref_tbl_offset);
>> -    }
>> -    build_header(linker, table_data,
>> -                 (void *)rsdt, "RSDT", rsdt_len, 1, oem_id, oem_table_id);
>> -}
>> -
>>  /* Build xsdt table */
>>  void
>>  build_xsdt(GArray *table_data, BIOSLinker *linker, GArray *table_offsets,
>> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>> index 6b7bade183..ad00f6affd 100644
>> --- a/hw/i386/acpi-build.c
>> +++ b/hw/i386/acpi-build.c
>> @@ -2557,12 +2557,12 @@ build_amd_iommu(GArray *table_data, BIOSLinker *linker)
>>  }
>>
>>  static GArray *
>> -build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned rsdt_tbl_offset)
>> +build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned xsdt_tbl_offset)
>>  {
>>      AcpiRsdpDescriptor *rsdp = acpi_data_push(rsdp_table, sizeof *rsdp);
>> -    unsigned rsdt_pa_size = sizeof(rsdp->rsdt_physical_address);
>> -    unsigned rsdt_pa_offset =
>> -        (char *)&rsdp->rsdt_physical_address - rsdp_table->data;
>> +    unsigned xsdt_pa_size = sizeof(rsdp->xsdt_physical_address);
>> +    unsigned xsdt_pa_offset =
>> +        (char *)&rsdp->xsdt_physical_address - rsdp_table->data;
>>
>>      bios_linker_loader_alloc(linker, ACPI_BUILD_RSDP_FILE, rsdp_table, 16,
>>                               true /* fseg memory */);
>> @@ -2571,8 +2571,8 @@ build_rsdp(GArray *rsdp_table, BIOSLinker *linker, unsigned rsdt_tbl_offset)
>>      memcpy(rsdp->oem_id, ACPI_BUILD_APPNAME6, 6);
>>      /* Address to be filled by Guest linker */
>>      bios_linker_loader_add_pointer(linker,
>> -        ACPI_BUILD_RSDP_FILE, rsdt_pa_offset, rsdt_pa_size,
>> -        ACPI_BUILD_TABLE_FILE, rsdt_tbl_offset);
>> +        ACPI_BUILD_RSDP_FILE, xsdt_pa_offset, xsdt_pa_size,
>> +        ACPI_BUILD_TABLE_FILE, xsdt_tbl_offset);
>>
>>      /* Checksum to be filled by Guest linker */
>>      bios_linker_loader_add_checksum(linker, ACPI_BUILD_RSDP_FILE,
>> @@ -2621,7 +2621,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
>>      PCMachineState *pcms = PC_MACHINE(machine);
>>      PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
>>      GArray *table_offsets;
>> -    unsigned facs, dsdt, rsdt, fadt;
>> +    unsigned facs, dsdt, xsdt, fadt;
>>      AcpiPmInfo pm;
>>      AcpiMiscInfo misc;
>>      AcpiMcfgInfo mcfg;
>> @@ -2730,12 +2730,12 @@ void acpi_build(AcpiBuildTables *tables, MachineState *machine)
>>      }
>>
>>      /* RSDT is pointed to by RSDP */
>> -    rsdt = tables_blob->len;
>> -    build_rsdt(tables_blob, tables->linker, table_offsets,
>> +    xsdt = tables_blob->len;
>> +    build_xsdt(tables_blob, tables->linker, table_offsets,
>>                 slic_oem.id, slic_oem.table_id);
>>
>>      /* RSDP is in FSEG memory, so allocate it separately */
>> -    build_rsdp(tables->rsdp, tables->linker, rsdt);
>> +    build_rsdp(tables->rsdp, tables->linker, xsdt);
>>
>>      /* We'll expose it all to Guest so we want to reduce
>>       * chance of size changes.
>>
>>
>> SeaBIOS:
>>
>> From 73b0facdb7349f5dbf24dc675647b68eeeec0ff4 Mon Sep 17 00:00:00 2001
>> From: Paolo Bonzini <pbonzini@redhat.com>
>> Date: Tue, 25 Jul 2017 18:50:19 +0200
>> Subject: [PATCH 1/2] seabios: build RSDT from XSDT
>>
>> Old operating systems would like to have a v1 FADT, but new
>> operating systems would like to have v3.
>>
>> Since old operating systems do not know about XSDTs, the
>> solution is to point the RSDT to a v1 FADT and the XSDT to a
>> v3 FADT.
>>
>> But, OVMF is not able to do that and barfs when it sees the
>> second FADT---plus really it's only BIOS operating systems
>> such as win2k that complain.  So instead: 1) make QEMU provide
>> an XSDT only; 2) build the RSDT and v1 FADT in SeaBIOS.
>>
>> This patch makes SeaBIOS build an RSDT out of an existing XSDT.
>>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>>  src/fw/paravirt.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
>>  src/std/acpi.h    | 11 +++++++++++
>>  2 files changed, 55 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
>> index 5b23d78..19a4abe 100644
>> --- a/src/fw/paravirt.c
>> +++ b/src/fw/paravirt.c
>> @@ -25,6 +25,7 @@
>>  #include "x86.h" // cpuid
>>  #include "xen.h" // xen_biostable_setup
>>  #include "stacks.h" // yield
>> +#include "std/acpi.h"
>>
>>  // Amount of continuous ram under 4Gig
>>  u32 RamSize;
>> @@ -147,6 +148,46 @@ static void msr_feature_control_setup(void)
>>          wrmsr_smp(MSR_IA32_FEATURE_CONTROL, feature_control_bits);
>>  }
>>
>> +static void
>> +build_compatibility_rsdt(void)
>> +{
>> +    if (RsdpAddr->rsdt_physical_address)
>> +        return;
>> +
>> +    u64 xsdt_addr = RsdpAddr->xsdt_physical_address;
>> +    if (xsdt_addr & ~0xffffffffULL)
>> +        return;
>> +
>> +    struct xsdt_descriptor_rev1 *xsdt = (void*)(u32)xsdt_addr;
>> +    void *end = (void*)xsdt + xsdt->length;
>> +    struct rsdt_descriptor_rev1 *rsdt;
>> +    int rsdt_size = offsetof(struct rsdt_descriptor_rev1, table_offset_entry[0]);
>> +    int i;
>> +    for (i=0; (void*)&xsdt->table_offset_entry[i] < end; i++) {
>> +        u64 tbl_addr = xsdt->table_offset_entry[i];
>> +        if (!tbl_addr || (tbl_addr & ~0xffffffffULL))
>> +            continue;
>> +        rsdt_size += 4;
>> +    }
>> +
>> +    rsdt = malloc_high(rsdt_size);
>> +    RsdpAddr->rsdt_physical_address = (u32)rsdt;
> 
> Modifying the RSDP like this invalidates both its checksums, so they
> need to be adjusted. Something like this:
> 
>     RsdpAddr->checksum -= checksum(RsdpAddr, offsetof(struct
> rsdp_descriptor, length));
>     RsdpAddr->extended_checksum -= checksum(RsdpAddr, sizeof(struct
> rsdp_descriptor));
> 
>> +
>> +    memcpy(rsdt, xsdt, sizeof(struct acpi_table_header));
>> +    rsdt->signature = RSDT_SIGNATURE;
>> +    rsdt->length = rsdt_size;
>> +    rsdt->revision = 1;
>> +    int j;
>> +    for (i=j=0; (void*)&xsdt->table_offset_entry[i] < end; i++) {
>> +        u64 tbl_addr = xsdt->table_offset_entry[i];
>> +        if (!tbl_addr || (tbl_addr & ~0xffffffffULL))
>> +            continue;
>> +        rsdt->table_offset_entry[j++] = (u32)tbl_addr;
>> +    }
>> +
>> +    rsdt->checksum -= checksum(rsdt, rsdt_size);
>> +}
>> +
>>  void
>>  qemu_platform_setup(void)
>>  {
>> @@ -186,8 +227,10 @@ qemu_platform_setup(void)
>>
>>          RsdpAddr = find_acpi_rsdp();
>>
>> -        if (RsdpAddr)
>> +        if (RsdpAddr) {
>> +            build_compatibility_rsdt();
>>              return;
>> +        }
>>
>>          /* If present, loader should have installed an RSDP.
>>           * Not installed? We might still be able to continue
>> diff --git a/src/std/acpi.h b/src/std/acpi.h
>> index c2ea707..caf5e7e 100644
>> --- a/src/std/acpi.h
>> +++ b/src/std/acpi.h
>> @@ -133,6 +133,17 @@ struct rsdt_descriptor_rev1
>>  } PACKED;
>>
>>  /*
>> + * ACPI 2.0 Root System Description Table (RSDT)
>> + */
> 
> Comment should be "ACPI 2.0 Extended System Description Table (XSDT)"
> 
>> +#define XSDT_SIGNATURE 0x54445358 // RSDT
> 
> The signature is "XSDT", that works out to 0x58445358
> 
>> +struct xsdt_descriptor_rev1
>> +{
>> +    ACPI_TABLE_HEADER_DEF       /* ACPI common table header */
>> +    u64 table_offset_entry[0];  /* Array of pointers to other */
>> +    /* ACPI tables */
>> +} PACKED;
>> +
>> +/*
>>   * ACPI 1.0 Firmware ACPI Control Structure (FACS)
>>   */
>>  #define FACS_SIGNATURE 0x53434146 // FACS
>> --
>> 2.13.3
>>
>>
>> From 46c7a296d27bd487cfd89a40973b1e61426dfbd0 Mon Sep 17 00:00:00 2001
>> From: Paolo Bonzini <pbonzini@redhat.com>
>> Date: Tue, 25 Jul 2017 18:59:20 +0200
>> Subject: [PATCH 2/2] seabios: create v1 FADT in compatibility RSDT
>>
>> This patch presents a v1 FADT inside the compatibility RSDT, so
>> that old operating systems are not broken.
>>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>>  src/fw/paravirt.c | 18 +++++++++++++++
>>  1 file changed, 18 insertions(+)
>>
>> diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
>> index 19a4abe..a9b9e80 100644
>> --- a/src/fw/paravirt.c
>> +++ b/src/fw/paravirt.c
>> @@ -148,6 +148,18 @@ static void msr_feature_control_setup(void)
>>          wrmsr_smp(MSR_IA32_FEATURE_CONTROL, feature_control_bits);
>>  }
>>
>> +static void*
>> +build_rev1_fadt(struct fadt_descriptor_rev1 *fadt_v3)
>> +{
>> +    struct fadt_descriptor_rev1 *fadt_v1 = malloc_high(sizeof *fadt_v1);
>> +
>> +    memcpy(fadt_v1, fadt_v3, sizeof *fadt_v1);
>> +    fadt_v1->length = sizeof *fadt_v1;
>> +    fadt_v1->revision = 1;
> 
> We should mask out the flags bits that are reserved in ACPI 1.0 as
> they refer to fields not present in this revision's FADT. e.g.
> 
>     // upper 23 bits reserved in rev1 FADT
>     fadt_v1->flags &= 0x1ff;
> 
> 
>> +    fadt_v1->checksum -= checksum(fadt_v1, fadt_v1->length);
>> +    return fadt_v1;
>> +}
>> +
>>  static void
>>  build_compatibility_rsdt(void)
>>  {
>> @@ -182,6 +194,12 @@ build_compatibility_rsdt(void)
>>          u64 tbl_addr = xsdt->table_offset_entry[i];
>>          if (!tbl_addr || (tbl_addr & ~0xffffffffULL))
>>              continue;
>> +        struct acpi_table_header *tbl = (void*)(u32)tbl_addr;
>> +        /* The RSDT should only have an ACPI 1.0 FADT according to
>> +         * the spec.
>> +         */
>> +        if (tbl->signature == FACP_SIGNATURE && tbl->revision > 1)
>> +            tbl_addr = (u32)build_rev1_fadt((void *)tbl);
>>          rsdt->table_offset_entry[j++] = (u32)tbl_addr;
>>      }
>>
>> --
>> 2.13.3
>>
>>
> 
> With these changes:
> 
> Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu>
> 

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

[Laszlo Ersek]

Digressing:

On 07/26/17 10:53, Paolo Bonzini wrote:
> On 25/07/2017 23:25, Phil Dennis-Jordan wrote:
>> Thanks for this, Paolo. Very interesting idea.
>>
>> I couldn't get things working initially, but with a few fixups on the
>> SeaBIOS side I can boot both legacy and modern OSes. See comments
>> inline below for details on changes required.
>>
>> Successfully booted (only a brief test):
>> - Windows 2000
>> - Windows XP (32 bit)
>> - Windows 7 (32 bit)
>> - Windows 10 (64 bit, SeaBIOS)
>> - Windows 10 (64 bit, OVMF)
>> - macOS 10.12 (patched OVMF)
>
> Thanks Phil!  You unwittingly tested the compatibility path on all
> these OSes, since my QEMU patch forgot to setup rsdp->length,
> rsdp->revision and the extended checksum.  However, I've now tested
> Windows XP, Linux w/SeaBIOS, Linux w/patched SeaBIOS and Linux w/OVMF.
>
> I've now found out that edk2 contains similar logic.  It uses a PCD (a
> compile-time flag essentially) to choose between ACPI >= 2.0 tables or
> ACPI 1.0-compatible tables.  In the latter case, edk2 takes care of
> producing a v1 FADT if needed (similar to this patch) and linking the
> RSDT to it; otherwise it keeps whatever FADT was provided by platform
> code and produces an XSDT.

Not exactly; the PCD controls whether the EFI_ACPI_TABLE_PROTOCOL will
expose an RSDT, an XSDT, or both (with matching contents). The FADT
always comes from the specific edk2 platform (i.e., OVMF client code),
and it is not translated in any way, regardless of the PCD value.

>From "MdeModulePkg/MdeModulePkg.dec":

>   ## Indicates which ACPI versions are targeted by the ACPI tables exposed to the OS
>   #  These values are aligned with the definitions in MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>   #   BIT 1 - EFI_ACPI_TABLE_VERSION_1_0B.<BR>
>   #   BIT 2 - EFI_ACPI_TABLE_VERSION_2_0.<BR>
>   #   BIT 3 - EFI_ACPI_TABLE_VERSION_3_0.<BR>
>   #   BIT 4 - EFI_ACPI_TABLE_VERSION_4_0.<BR>
>   #   BIT 5 - EFI_ACPI_TABLE_VERSION_5_0.<BR>
>   # @Prompt Exposed ACPI table versions.
>   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x3E|UINT32|0x0001004c

The expectation is that the specific edk2 platform overrides this PCD at
build time (if necessary), and then goes on (at boot time) to install
ACPI tables -- using EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() -- that
actually match the PCD setting.

>From the "MdeModulePkg/Universal/Acpi/AcpiTableDxe/" driver's POV (that
is, from the EFI_ACPI_TABLE_PROTOCOL implementation's POV), the platform
controls *both* the PCD and the actually installed tables like the FADT,
so EFI_ACPI_TABLE_PROTOCOL expects the platform to make these
consistent.

The tiny little problem is that the PCD is a build-time flag, but QEMU
provides the FADT (and friends) at boot time, dynamically, in a format
that is essentially opaque to OVMF. So OVMF is sticking with the default
PCD (see above), resulting in both RSDT and XSDT root tables, regardless
of the contents of the FADT and friends.

A somewhat (but not too much) similar situation is with the SMBIOS
tables. The tables are composed / exported by QEMU over fw_cfg, and OVMF
/ AAVMF have to set some version-like PCDs that match the content:
- PcdSmbiosDocRev
- PcdSmbiosVersion

We do some ugly hacks in OVMF to ensure that these PCDs are set "in
time", before the generic "MdeModulePkg/Universal/SmbiosDxe" --
providing EFI_SMBIOS_PROTOCOL -- starts up and consumes the PCDs.
Namely, we have "OvmfPkg/Library/SmbiosVersionLib" which sets these PCDs
based on fw_cfg, and we link this library via NULL class resolution into
"MdeModulePkg/Universal/SmbiosDxe". So the PCDs will be set up just
before EFI_SMBIOS_PROTOCOL is initialized and provided. In turn,
"OvmfPkg/SmbiosPlatformDxe", which actually calls
EFI_SMBIOS_PROTOCOL.Add() on the tables provided by QEMU, has a depex on
EFI_SMBIOS_PROTOCOL -- first, this depex ensures that
EFI_SMBIOS_PROTOCOL can be used by "OvmfPkg/SmbiosPlatformDxe", but
second, the depex *also* ensures that the PCDs will have been set
correctly by the time "OvmfPkg/SmbiosPlatformDxe" calls
EFI_SMBIOS_PROTOCOL.Add() for the first time.

You might ask why we don't do the same in the ACPI case (i.e., for
PcdAcpiExposedTableVersions). It's due to the following differences:

- (less importantly,) "MdeModulePkg.dec" allows platforms to pick
  "dynamic" for PcdSmbiosDocRev and PcdSmbiosVersion, not just "fixed at
  build". IOW, MdeModulePkg already expects platforms to set the SMBIOS
  version PCDs dynamically, if those platforms can ensure the setting
  occurs "early enough".

- (more importantly,) the information needed by OVMF, for setting the
  SMBIOS version PCDs in "OvmfPkg/Library/SmbiosVersionLib", is readily
  available for parsing from the separate, dedicated fw_cfg file called
  "etc/smbios/smbios-anchor". In fact, OVMF doesn't use this file for
  anything else than grabbing the versions for the PCDs. The actual
  "anchor" table (the smbios entry point) is produced by the
  EFI_SMBIOS_PROTOCOL implementation in
  "MdeModulePkg/Universal/SmbiosDxe", which consumes the version PCDs.

  (The SMBIOS tables themselves are provided in another fw_cfg file,
  called "etc/smbios/smbios-tables". Incidentally, the structure of that
  file is also way simpler than the ACPI linker/loader blobs'; OVMF can
  pick it apart with a simple loop and pass the individual SMBIOS tables
  to EFI_SMBIOS_PROTOCOL.Add().)

Anyway, I'm calling this email a digression because it isn't really
related to the FADT content that is exposed to the OS. I just wanted to
clarify "PcdAcpiExposedTableVersions", and that there isn't any "deep"
FADT translation in edk2, to my knowledge.

Thanks
Laszlo

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

[Paolo Bonzini]

On 26/07/2017 13:42, Laszlo Ersek wrote:
> Not exactly; the PCD controls whether the EFI_ACPI_TABLE_PROTOCOL will
> expose an RSDT, an XSDT, or both (with matching contents).

You're right that the code does not produce a v1 FADT, I mis-skimmed the
awful code of AcpiTableDxe.  Though the intentions seems to be there in
the UEFI spec, because UEFI has different GUIDs for ACPI 1.0 and 2.0+
RSDPs---and they need not point to the same tables, even though the ACPI
1.0 RSDP is a subset of the 2.0+ one.

AcpiTableDxe's data structures have an "Rsdp1" field (pointing to
"Rsdt1" and from there to "Fadt1") and an "Rsdp3" field (pointing to
"Xsdt" and optionally "Rsdt3", and from both to "Fadt3").  However:

* Fadt1 and Fadt3 have exactly the same content.

* Rsdt3 doesn't point to Fadt1.

It should be easy to make "Fadt1" a v1 table instead of copying the same
contents to Fadt1 and Fadt3, and to make Rsdt3 point to Fadt1.  The CSM
would just work if edk2 did this; until then Windows 2000 over SeaBIOS
over OVMF remains broken, but I guess that's not that much of an issue.

Anyway, once you take CSM into account, IMHO a firmware solution becomes
preferrable to Kevin's proposals to add a etc/table-loader-legacy (or
similar) file in fw_cfg.

Paolo

> The FADT
> always comes from the specific edk2 platform (i.e., OVMF client code),
> and it is not translated in any way, regardless of the PCD value.
> 
> From "MdeModulePkg/MdeModulePkg.dec":
> 
>>   ## Indicates which ACPI versions are targeted by the ACPI tables exposed to the OS
>>   #  These values are aligned with the definitions in MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>>   #   BIT 1 - EFI_ACPI_TABLE_VERSION_1_0B.<BR>
>>   #   BIT 2 - EFI_ACPI_TABLE_VERSION_2_0.<BR>
>>   #   BIT 3 - EFI_ACPI_TABLE_VERSION_3_0.<BR>
>>   #   BIT 4 - EFI_ACPI_TABLE_VERSION_4_0.<BR>
>>   #   BIT 5 - EFI_ACPI_TABLE_VERSION_5_0.<BR>
>>   # @Prompt Exposed ACPI table versions.
>>   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x3E|UINT32|0x0001004c
> The expectation is that the specific edk2 platform overrides this PCD at
> build time (if necessary), and then goes on (at boot time) to install
> ACPI tables -- using EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() -- that
> actually match the PCD setting.

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

[Igor Mammedov]

On Tue, 25 Jul 2017 18:23:22 +0200
Paolo Bonzini <pbonzini@redhat.com> 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.

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.  
> 

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 <pbonzini@redhat.com> 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.  
>>
> 

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

[Igor Mammedov]

On Wed, 26 Jul 2017 15:10:40 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 26/07/2017 15:08, Igor Mammedov wrote:
> > On Tue, 25 Jul 2017 18:23:22 +0200
> > Paolo Bonzini <pbonzini@redhat.com> 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?
they are rebuild on reset, but I've been wrong
Looking at SeaBIOS something similar to your suggestion also should work,
 if 
    RsdpAddr = find_acpi_rsdp();
 fails, current SeaBIOS falls back to its own ACPI tables.

but it seems that we don't even need to go to that extent,
all user have to do is to use "-no-acpi" CLI option with QEMU
for any SeaBIOS to fallback to embedded legacy ACPI tables.

Maybe we should just fix wiki
  http://wiki.qemu.org/Windows2000
to recommend using '-no-acpi' option when running w2k and
leave PC machine at rev3 and mention it in release notes.

Opinions?

> 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.    
> >>  
> >   
> 

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

[Paolo Bonzini]

On 26/07/2017 15:30, Igor Mammedov wrote:
> On Wed, 26 Jul 2017 15:10:40 +0200
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> On 26/07/2017 15:08, Igor Mammedov wrote:
>>> On Tue, 25 Jul 2017 18:23:22 +0200
>>> Paolo Bonzini <pbonzini@redhat.com> 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?
> they are rebuild on reset, but I've been wrong

Hmm so we need this plus keeping old machine types fixed to rev1 and
RSDT.  Diffstat will get worse. :)

Paolo

> Looking at SeaBIOS something similar to your suggestion also should work,
>  if 
>     RsdpAddr = find_acpi_rsdp();
>  fails, current SeaBIOS falls back to its own ACPI tables.
> 
> but it seems that we don't even need to go to that extent,
> all user have to do is to use "-no-acpi" CLI option with QEMU
> for any SeaBIOS to fallback to embedded legacy ACPI tables.
> 
> Maybe we should just fix wiki
>   http://wiki.qemu.org/Windows2000
> to recommend using '-no-acpi' option when running w2k and
> leave PC machine at rev3 and mention it in release notes.
> 
> Opinions?
> 
>> 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.    
>>>>  
>>>   
>>
> 

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

[Igor Mammedov]

On Wed, 26 Jul 2017 15:33:37 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 26/07/2017 15:30, Igor Mammedov wrote:
> > On Wed, 26 Jul 2017 15:10:40 +0200
> > Paolo Bonzini <pbonzini@redhat.com> wrote:
> >   
> >> On 26/07/2017 15:08, Igor Mammedov wrote:  
> >>> On Tue, 25 Jul 2017 18:23:22 +0200
> >>> Paolo Bonzini <pbonzini@redhat.com> 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?  
> > they are rebuild on reset, but I've been wrong  
> 
> Hmm so we need this plus keeping old machine types fixed to rev1 and
> RSDT.  Diffstat will get worse. :)
Even though I'd prefer to tie revision switch to machine type+version,
and kill rev1 support along with machine type when it's removed
v1, https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg06822.html,

there were objections to it and Michael suggested to use just rev1
for PC based machine types and rev3 for Q35 based machine types.

 
> Paolo
> 
> > Looking at SeaBIOS something similar to your suggestion also should work,
> >  if 
> >     RsdpAddr = find_acpi_rsdp();
> >  fails, current SeaBIOS falls back to its own ACPI tables.
> > 
> > but it seems that we don't even need to go to that extent,
> > all user have to do is to use "-no-acpi" CLI option with QEMU
> > for any SeaBIOS to fallback to embedded legacy ACPI tables.
> > 
> > Maybe we should just fix wiki
> >   http://wiki.qemu.org/Windows2000
> > to recommend using '-no-acpi' option when running w2k and
> > leave PC machine at rev3 and mention it in release notes.
> > 
> > Opinions?
> >   
> >> 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.      
> >>>>    
> >>>     
> >>  
> >   
> 

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

[Michael S. Tsirkin]

On Wed, Jul 26, 2017 at 03:30:20PM +0200, Igor Mammedov wrote:
> On Wed, 26 Jul 2017 15:10:40 +0200
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> > On 26/07/2017 15:08, Igor Mammedov wrote:
> > > On Tue, 25 Jul 2017 18:23:22 +0200
> > > Paolo Bonzini <pbonzini@redhat.com> 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?
> they are rebuild on reset, but I've been wrong
> Looking at SeaBIOS something similar to your suggestion also should work,
>  if 
>     RsdpAddr = find_acpi_rsdp();
>  fails, current SeaBIOS falls back to its own ACPI tables.
> 
> but it seems that we don't even need to go to that extent,
> all user have to do is to use "-no-acpi" CLI option with QEMU
> for any SeaBIOS to fallback to embedded legacy ACPI tables.
> 
> Maybe we should just fix wiki
>   http://wiki.qemu.org/Windows2000
> to recommend using '-no-acpi' option when running w2k and
> leave PC machine at rev3 and mention it in release notes.
> 
> Opinions?

I really don't want to go back and have to support the builtin ACPI
tables. Not worth the small hassle of maintaining RSDP in QEMU.

At some point we will want to split up ACPI code, leave PC
alone and add stuff for Q35 only. Maybe not yet though.


> > 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.    
> > >>  
> > >   
> > 

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

[Daniel P. Berrange]

On Wed, Jul 26, 2017 at 03:43:43PM +0200, Igor Mammedov wrote:
> On Wed, 26 Jul 2017 15:33:37 +0200
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> > On 26/07/2017 15:30, Igor Mammedov wrote:
> > > On Wed, 26 Jul 2017 15:10:40 +0200
> > > Paolo Bonzini <pbonzini@redhat.com> wrote:
> > >   
> > >> On 26/07/2017 15:08, Igor Mammedov wrote:  
> > >>> On Tue, 25 Jul 2017 18:23:22 +0200
> > >>> Paolo Bonzini <pbonzini@redhat.com> 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?  
> > > they are rebuild on reset, but I've been wrong  
> > 
> > Hmm so we need this plus keeping old machine types fixed to rev1 and
> > RSDT.  Diffstat will get worse. :)
> Even though I'd prefer to tie revision switch to machine type+version,
> and kill rev1 support along with machine type when it's removed
> v1, https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg06822.html,

We're unlikely to be deleting machine types (and the features they
depend on) for as long as there's downstream vendors who need compat
with that vintage of features. So given RHEL lifetimes, a pc-2.8
machine type (and features it needs) will be around another 10-15
years. So making decisions based on an expectation of deleting
machine types any time soon is questionable.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

[Michael S. Tsirkin]

On Wed, Jul 26, 2017 at 03:04:59PM +0100, Daniel P. Berrange wrote:
> We're unlikely to be deleting machine types (and the features they
> depend on) for as long as there's downstream vendors who need compat
> with that vintage of features.

.. and actually put in the manpower to maintain them :)

-- 
MST

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

[Kevin O'Connor]

On Wed, Jul 26, 2017 at 09:20:16AM +0200, Paolo Bonzini wrote:
> On 26/07/2017 00:01, Kevin O'Connor wrote:
> > On Tue, Jul 25, 2017 at 07:10:21PM +0200, Paolo Bonzini wrote:
> >> On 25/07/2017 18:23, Paolo Bonzini 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.
> > 
> > It's an impressive hack!
> > 
> >>>
> >>> All QEMU would have to do is to provide an XSDT _instead_ of an RSDT.
> > [...]
> >> SeaBIOS:
> >>
> >> From 73b0facdb7349f5dbf24dc675647b68eeeec0ff4 Mon Sep 17 00:00:00 2001
> >> From: Paolo Bonzini <pbonzini@redhat.com>
> >> Date: Tue, 25 Jul 2017 18:50:19 +0200
> >> Subject: [PATCH 1/2] seabios: build RSDT from XSDT
> >>
> >> Old operating systems would like to have a v1 FADT, but new
> >> operating systems would like to have v3.
> >>
> >> Since old operating systems do not know about XSDTs, the
> >> solution is to point the RSDT to a v1 FADT and the XSDT to a
> >> v3 FADT.
> >>
> >> But, OVMF is not able to do that and barfs when it sees the
> >> second FADT---plus really it's only BIOS operating systems
> >> such as win2k that complain.  So instead: 1) make QEMU provide
> >> an XSDT only; 2) build the RSDT and v1 FADT in SeaBIOS.
> >>
> >> This patch makes SeaBIOS build an RSDT out of an existing XSDT.
> > 
> > I'd really prefer not to have SeaBIOS go back to producing ACPI
> > tables.
> 
> Me too, but this is different from SeaBIOS producing ACPI tables.
> (Patched) QEMU produces entirely valid ACPI 2.0 tables, while SeaBIOS is
> only producing compatibility glue for old OSes.  Compared to producing
> ACPI tables, SeaBIOS needs no knowledge of the underlying hardware, only
> of the limitations of those old OSes.  Responsibilities between QEMU and
> SeaBIOS are nicely split.
> 
> > As an alternative, how about some other possible hacks:
> > 
> > 1 - ovmf filters out the extra tables that it barfs on.
> > 
> > 2 - change ovmf to read the fw_cfg linker script
> >     'etc/table-loader-ovmf' instead of '/etc/table-loader' and change
> >     qemu to generate two linker scripts - one for seabios and one for
> >     ovmf.
> > 
> > 3 - same as 2, but change seabios to use 'etc/table-loader-seabios'
> >     and leave ovmf unchanged.
> > 
> > 4 - change seabios to read both the linker script 'etc/table-loader'
> >     _and_ some new linker script '/etc/table-loader-legacy'.  Have
> >     qemu introduce the RSDT/FADTv1 in the "legacy" linker script.
> 
> (4) would be acceptable I guess.  However I think it's a bit worse
> because fw-cfg files are a somewhat scarce resource.  The "legacy"
> aspect is something that SeaBIOS is in the best position to address,
> because it knows what OSes are running on it; QEMU instead only takes
> care of describing the hardware.

SeaBIOS is used with both modern and legacy OSes, and it doesn't have
any knowledge about what kind of OS will be used.  If anything, I'd
argue that QEMU has more knowledge about the guest OS than SeaBIOS
does (due to command-line options like machine version).

As I see it, fundamentally the proposal here is to deploy different
ACPI tables when using SeaBIOS then when using OVMF.  I think that's
fine, but I think we should directly address that issue then.

Specifically, I have the following concerns with the original approach:

A - It would require deploying SeaBIOS and QEMU in lock-step.  To get
    this in for QEMU v2.10 would require making QEMU changes during
    the soft freeze and would require a SeaBIOS "stable" release that
    introduces ACPI table manipulation.

B - I don't have full confidence the proposed ACPI changes wont expose
    a quirk in some obscure OS from the last 25 years.  If it does
    expose a quirk, any work-around would likely require deploying a
    new SeaBIOS and QEMU in lock-step.

C - We'd be introducing "shared ownership" of the acpi tables.  Some
    of the tables would be produced by QEMU and some of them by
    SeaBIOS.  Explaining when and why to future developers would be a
    challenge.

-Kevin

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

[Paolo Bonzini]

> > (4) would be acceptable I guess.  However I think it's a bit worse
> > because fw-cfg files are a somewhat scarce resource.  The "legacy"
> > aspect is something that SeaBIOS is in the best position to address,
> > because it knows what OSes are running on it; QEMU instead only takes
> > care of describing the hardware.
> 
> SeaBIOS is used with both modern and legacy OSes, and it doesn't have
> any knowledge about what kind of OS will be used.  If anything, I'd
> argue that QEMU has more knowledge about the guest OS than SeaBIOS
> does (due to command-line options like machine version).

No, the machine type is independent from the guest OS.  The aim is to
let "qemu-system-x86_64 -m MEMORYSZ image.qcow2" work just fine with
every guest OS.

> As I see it, fundamentally the proposal here is to deploy different
> ACPI tables when using SeaBIOS then when using OVMF.  I think that's
> fine, but I think we should directly address that issue then.

The different ACPI tables are essentially a bug in OVMF.  They can be
fixed to be the same.

> Specifically, I have the following concerns with the original approach:
> 
> A - It would require deploying SeaBIOS and QEMU in lock-step.  To get
>     this in for QEMU v2.10 would require making QEMU changes during
>     the soft freeze and would require a SeaBIOS "stable" release that
>     introduces ACPI table manipulation.

Yes.

> B - I don't have full confidence the proposed ACPI changes wont expose
>     a quirk in some obscure OS from the last 25 years.  If it does
>     expose a quirk, any work-around would likely require deploying a
>     new SeaBIOS and QEMU in lock-step.

Well, the solution is proposed by ACPI itself, and the worst that can
happen is that some OS prefers the RSDT to the XSDT (which we already
test on Windows 2000).

> C - We'd be introducing "shared ownership" of the acpi tables.  Some
>     of the tables would be produced by QEMU and some of them by
>     SeaBIOS.  Explaining when and why to future developers would be a
>     challenge.

The advantage is that the same shared ownership is already present in
OVMF.  The RSDP/RSDT/XSDT are entirely created by the firmware in OVMF.
(The rev1 FADT isn't but that's just missing code; the table manager
in general would be ready for that).  In any case this doesn't seem
like something that cannot be solved by code comments.

Paolo

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

[Gerd Hoffmann]

  Hi,

> > SeaBIOS is used with both modern and legacy OSes, and it doesn't
> > have
> > any knowledge about what kind of OS will be used.  If anything, I'd
> > argue that QEMU has more knowledge about the guest OS than SeaBIOS
> > does (due to command-line options like machine version).
> 
> No, the machine type is independent from the guest OS.

Well, not really.  Old guests (winxp & older) don't do very well on pc.
 Modern ones are better served with q35, because they either don't boot
on pc (macos I think) or can use the features of the modern hardware,
like pci express.

I still like the idea to have pc machine type provide the older stuff. 
The hardware we emulate for the pc machine type is old enough that old
acpi versions should have no problems describing it.

> > A - It would require deploying SeaBIOS and QEMU in lock-step.  To
> > get
> >     this in for QEMU v2.10 would require making QEMU changes during
> >     the soft freeze and would require a SeaBIOS "stable" release
> > that
> >     introduces ACPI table manipulation.
> 
> Yes.

Since the switch to qemu-generated acpi tables we were able to avoid
that kind of lockstep updates, I'd prefer to not loose that.

> > B - I don't have full confidence the proposed ACPI changes wont
> > expose
> >     a quirk in some obscure OS from the last 25 years.  If it does
> >     expose a quirk, any work-around would likely require deploying
> > a
> >     new SeaBIOS and QEMU in lock-step.
> 
> Well, the solution is proposed by ACPI itself, and the worst that can
> happen is that some OS prefers the RSDT to the XSDT (which we already
> test on Windows 2000).
> 
> > C - We'd be introducing "shared ownership" of the acpi
> > tables.  Some
> >     of the tables would be produced by QEMU and some of them by
> >     SeaBIOS.  Explaining when and why to future developers would be
> > a
> >     challenge.
> 
> The advantage is that the same shared ownership is already present in
> OVMF.  The RSDP/RSDT/XSDT are entirely created by the firmware in
> OVMF.

Hmm, seabios could do the same then, and we would not need a lockstep
update?

cheers,
  Gerd

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

[Paolo Bonzini]

On 27/07/2017 10:39, Gerd Hoffmann wrote:
>>> C - We'd be introducing "shared ownership" of the acpi
>>> tables.  Some
>>>     of the tables would be produced by QEMU and some of them by
>>>     SeaBIOS.  Explaining when and why to future developers would be
>>> a
>>>     challenge.
>>
>> The advantage is that the same shared ownership is already present in
>> OVMF.  The RSDP/RSDT/XSDT are entirely created by the firmware in
>> OVMF.
> 
> Hmm, seabios could do the same then, and we would not need a lockstep
> update?

That's fine by me too.  I'll try to make a patch.

Paolo

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

[Kevin O'Connor]

On Wed, Jul 26, 2017 at 04:21:23PM -0400, Paolo Bonzini wrote:
> > As I see it, fundamentally the proposal here is to deploy different
> > ACPI tables when using SeaBIOS then when using OVMF.  I think that's
> > fine, but I think we should directly address that issue then.
> 
> The different ACPI tables are essentially a bug in OVMF.  They can be
> fixed to be the same.
> 
> > Specifically, I have the following concerns with the original approach:
> > 
> > A - It would require deploying SeaBIOS and QEMU in lock-step.  To get
> >     this in for QEMU v2.10 would require making QEMU changes during
> >     the soft freeze and would require a SeaBIOS "stable" release that
> >     introduces ACPI table manipulation.
> 
> Yes.
> 
> > B - I don't have full confidence the proposed ACPI changes wont expose
> >     a quirk in some obscure OS from the last 25 years.  If it does
> >     expose a quirk, any work-around would likely require deploying a
> >     new SeaBIOS and QEMU in lock-step.
> 
> Well, the solution is proposed by ACPI itself, and the worst that can
> happen is that some OS prefers the RSDT to the XSDT (which we already
> test on Windows 2000).

Parsing the XSDT is a different code path in the OSes - it could
expose a quirk.  I'm fine with the new layout of the ACPI tables, but
I think we need to be prepared that the change could have a ripple
effect.

> > C - We'd be introducing "shared ownership" of the acpi tables.  Some
> >     of the tables would be produced by QEMU and some of them by
> >     SeaBIOS.  Explaining when and why to future developers would be a
> >     challenge.
> 
> The advantage is that the same shared ownership is already present in
> OVMF.  The RSDP/RSDT/XSDT are entirely created by the firmware in OVMF.
> (The rev1 FADT isn't but that's just missing code; the table manager
> in general would be ready for that).  In any case this doesn't seem
> like something that cannot be solved by code comments.

I'd argue that the shared ownership in the EDK2 code was a poor design
choice.  Case in point - we're only having this conversation because
of its limitations - SeaBIOS is capable of deploying the acpi tables
in the proposed layout without any code changes today.  I'm not
against changing SeaBIOS, but it's a priority for me that we continue
to make it possible to deploy future ACPI table changes (no matter how
quirky) in a way that does not require future SeaBIOS releases.

-Kevin

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

[Laszlo Ersek]

On 07/27/17 16:59, Kevin O'Connor wrote:
> On Wed, Jul 26, 2017 at 04:21:23PM -0400, Paolo Bonzini wrote:

>>> C - We'd be introducing "shared ownership" of the acpi tables.  Some
>>>     of the tables would be produced by QEMU and some of them by
>>>     SeaBIOS.  Explaining when and why to future developers would be
>>>     a challenge.
>>
>> The advantage is that the same shared ownership is already present in
>> OVMF.  The RSDP/RSDT/XSDT are entirely created by the firmware in
>> OVMF. (The rev1 FADT isn't but that's just missing code; the table
>> manager in general would be ready for that).  In any case this
>> doesn't seem like something that cannot be solved by code comments.
>
> I'd argue that the shared ownership in the EDK2 code was a poor design
> choice.

The reason we can't just exclude the reference implementation of
EFI_ACPI_TABLE_PROTOCOL from OVMF whole-sale, and reimplement the ACPI
linker/loader from scratch, is that some other (independent) edk2
modules will want to use EFI_ACPI_TABLE_PROTOCOL for installing their
own (one-off) tables, such as IBFT, BGRT and so on, *in addition to*
QEMU's. Given that these ACPI tables mostly do *not* describe hardware
(but software features and/or configuration), it's hard to claim that
they should also be generated by QEMU.

Therefore the dual origin for ACPI tables looks unavoidable in UEFI,
it's just that there should be a lot more flexible "connect" from QEMU's
linker/loader to the installed ACPI tables than EFI_ACPI_TABLE_PROTOCOL.

Basically this is a fight over ownership. Each of QEMU's ACPI
linker/loader and EFI_ACPI_TABLE_PROTOCOL thinks that it fully owns the
root of the table tree. :(

> Case in point - we're only having this conversation because of its
> limitations - SeaBIOS is capable of deploying the acpi tables in the
> proposed layout without any code changes today.

Yes.

But let's not forget that SeaBIOS is capable of delegating the full
low-level construction of the table tree to QEMU because no independent
/ 3rd party BIOS-level code wants to install its own tables (again,
IBFT, BGRT, ...) This is not true of UEFI, where the guiding principle
of the standardized interfaces is to enable cooperation between
independent, binary-only modules. (So, for example, if you shove a new
PCI add-on card in your motherboard, the UEFI driver in that oprom could
install a separate ACPI table, by looking up and calling
EFI_ACPI_TABLE_PROTOCOL.)

> I'm not against changing SeaBIOS, but it's a priority for me that we
> continue to make it possible to deploy future ACPI table changes (no
> matter how quirky) in a way that does not require future SeaBIOS
> releases.

It's a good goal.

I apologize for forgetting the context, but what exactly was the
argument against:

- splitting modern ACPI generation from ancient ACPI generation (so that
we can assign separate maintainers to ancient vs. modern),

- restricting ancient ACPI generation to old machine types?

Thanks,
Laszlo

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

[Gerd Hoffmann]

  Hi,

> It's a good goal.
> 
> I apologize for forgetting the context, but what exactly was the
> argument against:
> 
> - splitting modern ACPI generation from ancient ACPI generation (so
> that
> we can assign separate maintainers to ancient vs. modern),
> 
> - restricting ancient ACPI generation to old machine types?

I think this is the only sensible solution for 2.10:  Have "pc" provide
a rev1 FADT and "q35" provide a rev3 FADT.

Or just revert the rev3 FADT patch and try again in the 2.11 devel
cycle.

We are in qemu freeze and we don't even have a clear plan yet how to
implement the "RSDT points to rev1 and XSDT points to rev3" thing,
which IMO is a clear indicator that it isn't 2.10 material.

Beside that I'll be in my summer vacation next three weeks, so I can't
take care to create a seabios 1.10.3 release and update qemu ...

cheers,
  Gerd

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

[Programmingkid]

I just realized what we need in order to test QEMU better. We need a list of people who
are willing to support a certain operating system. 

The list would probably be located here: http://wiki.qemu.org/Testing/Windows

It would look like this:


Operating system	Tester

Windows 3.1		<email address of a tester>, <email address of another tester>, ...
Windows NT 3.1		<email address of a tester>, <email address of another tester>, ...
Windows NT 3.5		<email address of a tester>, <email address of another tester>, ...
Windows 95		<email address of a tester>, <email address of another tester>, ...
Windows NT 4.0		<email address of a tester>, <email address of another tester>, ...
Windows 98		<email address of a tester>, <email address of another tester>, ...
Windows ME		<email address of a tester>, <email address of another tester>, ...
Windows 2000		<email address of a tester>, <email address of another tester>, ...
Windows XP		<email address of a tester>, <email address of another tester>, ...
Windows Vista		<email address of a tester>, <email address of another tester>, ...
Windows 7		<email address of a tester>, <email address of another tester>, ...
Windows 8		<email address of a tester>, <email address of another tester>, ...
Windows 10		<email address of a tester>, <email address of another tester>, ...
ReactOS			<email address of a tester>, <email address of another tester>, ...


If someone has a patch that makes a change to the qemu-system-i386 emulator,
the patch maker can consult the list of people who might be willing to help test the patch. 
There are many people who work on QEMU with certain versions of Windows at their
disposal. With this knowledge compatibility testing can become more thorough.
Thoughts? Ideas?

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

[Programmingkid]

> On Jul 26, 2017, at 10:28 AM, qemu-devel-request@nongnu.org wrote:
> 
> Message: 3
> Date: Wed, 26 Jul 2017 15:30:20 +0200
> From: Igor Mammedov <imammedo@redhat.com>
> To: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Laszlo Ersek <lersek@redhat.com>, Phil Dennis-Jordan
> 	<lists@philjordan.eu>, "Daniel P. Berrange" <berrange@redhat.com>,
> 	Phil	Dennis-Jordan <phil@philjordan.eu>, ehabkost@redhat.com,
> 	"qemu-devel@nongnu.org qemu-devel" <qemu-devel@nongnu.org>,
> 	Programmingkid	<programmingkidx@gmail.com>, Richard Henderson
> 	<rth@twiddle.net>, "Michael	S. Tsirkin" <mst@redhat.com>
> Subject: Re: [Qemu-devel] Commit
> 	77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support
> Message-ID: <20170726153020.4c20b279@nial.brq.redhat.com>
> Content-Type: text/plain; charset=US-ASCII
> 
> On Wed, 26 Jul 2017 15:10:40 +0200
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> On 26/07/2017 15:08, Igor Mammedov wrote:
>>> On Tue, 25 Jul 2017 18:23:22 +0200
>>> Paolo Bonzini <pbonzini@redhat.com> 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?
> they are rebuild on reset, but I've been wrong
> Looking at SeaBIOS something similar to your suggestion also should work,
> if 
>    RsdpAddr = find_acpi_rsdp();
> fails, current SeaBIOS falls back to its own ACPI tables.
> 
> but it seems that we don't even need to go to that extent,
> all user have to do is to use "-no-acpi" CLI option with QEMU
> for any SeaBIOS to fallback to embedded legacy ACPI tables.
> 
> Maybe we should just fix wiki
>  http://wiki.qemu.org/Windows2000
> to recommend using '-no-acpi' option when running w2k and
> leave PC machine at rev3 and mention it in release notes.
> 
> Opinions?

I just tried booting Windows 2000 using '-no-acpi' and ended up in a restart loop.
Windows would look like its booting up properly then the screen is blanked.
Seabios text would appear on the screen for a fraction of a 
second then be replaced by the Windows startup screen again. This repeats over and
over.

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

[Programmingkid]

> On Jul 21, 2017, at 5:29 AM, qemu-devel-request@nongnu.org wrote:
> 
> From: Igor Mammedov <imammedo@redhat.com>
> 
> On Thu, 20 Jul 2017 21:29:33 +0200
> Phil Dennis-Jordan <lists@philjordan.eu> wrote:
> 
>> On Thu, Jul 20, 2017 at 6:40 PM, Programmingkid
>> <programmingkidx@gmail.com> wrote:
>>> I noticed that Windows 2000 does not boot up in QEMU recently. After bisecting the issue I found the offending commit:
> w2k is very ancient (and long time EOLed), I can't even download it from msdn to test
> (oldest available is XP)

If you really need to download Windows 2000, there may be other avenues you may want to try. 

> do we really care about it?

Yes. It is a great operating system. Very light weight, fast, and stable. The perfect operating system to use in an emulator.