All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Dennis-Jordan <lists@philjordan.eu>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "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>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support
Date: Fri, 21 Jul 2017 12:39:24 +0200	[thread overview]
Message-ID: <CAGCz3vvFyOEqbnEScZvmgOts+LNQ=vob5LwhSGURZMfPWZJf1Q@mail.gmail.com> (raw)
In-Reply-To: <20170721114623.57b3be1d@nial.brq.redhat.com>

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
>

  reply	other threads:[~2017-07-21 10:39 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-20 16:40 [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support Programmingkid
2017-07-20 19:29 ` Phil Dennis-Jordan
2017-07-21  0:00   ` Programmingkid
2017-07-21  9:06   ` Igor Mammedov
2017-07-21  9:11     ` Phil Dennis-Jordan
2017-07-21  9:23     ` Daniel P. Berrange
2017-07-21 12:34       ` Igor Mammedov
2017-07-21 18:29         ` Phil Dennis-Jordan
2017-07-25 16:14           ` Laszlo Ersek
2017-07-25 16:23             ` Paolo Bonzini
2017-07-25 17:10               ` Paolo Bonzini
2017-07-25 21:25                 ` Phil Dennis-Jordan
2017-07-26  8:53                   ` Paolo Bonzini
2017-07-26 11:42                     ` Laszlo Ersek
2017-07-26 12:06                       ` Paolo Bonzini
2017-07-25 22:01                 ` [Qemu-devel] [SeaBIOS] " Kevin O'Connor
2017-07-26  7:20                   ` Paolo Bonzini
2017-07-26 19:12                     ` Kevin O'Connor
2017-07-26 20:21                       ` Paolo Bonzini
2017-07-27  8:39                         ` Gerd Hoffmann
2017-07-27 12:26                           ` Paolo Bonzini
2017-07-27 14:59                         ` Kevin O'Connor
2017-07-27 17:46                           ` Laszlo Ersek
2017-07-28  6:57                             ` Gerd Hoffmann
2017-07-26 13:08               ` [Qemu-devel] " Igor Mammedov
2017-07-26 13:10                 ` Paolo Bonzini
2017-07-26 13:30                   ` Igor Mammedov
2017-07-26 13:33                     ` Paolo Bonzini
2017-07-26 13:43                       ` Igor Mammedov
2017-07-26 14:04                         ` Daniel P. Berrange
2017-07-26 16:13                           ` Michael S. Tsirkin
2017-07-26 13:57                     ` Michael S. Tsirkin
2017-07-24 12:45     ` Gerd Hoffmann
2017-07-24 16:43     ` John Snow
2017-07-24 17:30       ` Programmingkid
2017-07-21  9:20   ` Daniel P. Berrange
2017-07-21  9:46     ` Igor Mammedov
2017-07-21 10:39       ` Phil Dennis-Jordan [this message]
2017-07-21 10:50       ` BALATON Zoltan
2017-07-21 11:46         ` Phil Dennis-Jordan
2017-07-21 17:17           ` BALATON Zoltan
     [not found] <mailman.85963.1500629384.22737.qemu-devel@nongnu.org>
2017-07-21 16:00 ` Programmingkid
     [not found] <mailman.86860.1501079288.22738.qemu-devel@nongnu.org>
2017-07-27  2:38 ` Programmingkid
2017-07-27  3:23 Programmingkid

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGCz3vvFyOEqbnEScZvmgOts+LNQ=vob5LwhSGURZMfPWZJf1Q@mail.gmail.com' \
    --to=lists@philjordan.eu \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=phil@philjordan.eu \
    --cc=programmingkidx@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.