* [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support @ 2017-07-20 16:40 Programmingkid 2017-07-20 19:29 ` Phil Dennis-Jordan 0 siblings, 1 reply; 44+ messages in thread From: Programmingkid @ 2017-07-20 16:40 UTC (permalink / raw) To: Paolo Bonzini, Richard Henderson, ehabkost, phil Cc: qemu-devel@nongnu.org qemu-devel 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 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 ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Phil Dennis-Jordan @ 2017-07-20 19:29 UTC (permalink / raw) To: Programmingkid Cc: Paolo Bonzini, Richard Henderson, ehabkost, Phil Dennis-Jordan, qemu-devel@nongnu.org qemu-devel 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 > > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 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:20 ` Daniel P. Berrange 2 siblings, 0 replies; 44+ messages in thread From: Programmingkid @ 2017-07-21 0:00 UTC (permalink / raw) To: Phil Dennis-Jordan Cc: Paolo Bonzini, Richard Henderson, ehabkost, Phil Dennis-Jordan, qemu-devel@nongnu.org qemu-devel > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 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 ` (3 more replies) 2017-07-21 9:20 ` Daniel P. Berrange 2 siblings, 4 replies; 44+ messages in thread From: Igor Mammedov @ 2017-07-21 9:06 UTC (permalink / raw) To: Phil Dennis-Jordan Cc: Programmingkid, qemu-devel@nongnu.org qemu-devel, Paolo Bonzini, Phil Dennis-Jordan, ehabkost, Richard Henderson 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 > > > > > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-21 9:06 ` Igor Mammedov @ 2017-07-21 9:11 ` Phil Dennis-Jordan 2017-07-21 9:23 ` Daniel P. Berrange ` (2 subsequent siblings) 3 siblings, 0 replies; 44+ messages in thread From: Phil Dennis-Jordan @ 2017-07-21 9:11 UTC (permalink / raw) To: Igor Mammedov Cc: Programmingkid, qemu-devel@nongnu.org qemu-devel, Paolo Bonzini, Phil Dennis-Jordan, ehabkost, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 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-24 12:45 ` Gerd Hoffmann 2017-07-24 16:43 ` John Snow 3 siblings, 1 reply; 44+ messages in thread From: Daniel P. Berrange @ 2017-07-21 9:23 UTC (permalink / raw) To: Igor Mammedov Cc: Phil Dennis-Jordan, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Paolo Bonzini, Richard Henderson 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 :| ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-21 9:23 ` Daniel P. Berrange @ 2017-07-21 12:34 ` Igor Mammedov 2017-07-21 18:29 ` Phil Dennis-Jordan 0 siblings, 1 reply; 44+ messages in thread From: Igor Mammedov @ 2017-07-21 12:34 UTC (permalink / raw) To: Daniel P. Berrange Cc: Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Phil Dennis-Jordan, Paolo Bonzini, Richard Henderson, Laszlo Ersek 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-21 12:34 ` Igor Mammedov @ 2017-07-21 18:29 ` Phil Dennis-Jordan 2017-07-25 16:14 ` Laszlo Ersek 0 siblings, 1 reply; 44+ messages in thread From: Phil Dennis-Jordan @ 2017-07-21 18:29 UTC (permalink / raw) To: Igor Mammedov Cc: Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Paolo Bonzini, Richard Henderson, Laszlo Ersek 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 > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-21 18:29 ` Phil Dennis-Jordan @ 2017-07-25 16:14 ` Laszlo Ersek 2017-07-25 16:23 ` Paolo Bonzini 0 siblings, 1 reply; 44+ messages in thread From: Laszlo Ersek @ 2017-07-25 16:14 UTC (permalink / raw) To: Phil Dennis-Jordan, Igor Mammedov Cc: Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Paolo Bonzini, Richard Henderson 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 >> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-25 16:14 ` Laszlo Ersek @ 2017-07-25 16:23 ` Paolo Bonzini 2017-07-25 17:10 ` Paolo Bonzini 2017-07-26 13:08 ` [Qemu-devel] " Igor Mammedov 0 siblings, 2 replies; 44+ messages in thread From: Paolo Bonzini @ 2017-07-25 16:23 UTC (permalink / raw) To: Laszlo Ersek, Phil Dennis-Jordan, Igor Mammedov Cc: Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-25 16:23 ` Paolo Bonzini @ 2017-07-25 17:10 ` Paolo Bonzini 2017-07-25 21:25 ` Phil Dennis-Jordan 2017-07-25 22:01 ` [Qemu-devel] [SeaBIOS] " Kevin O'Connor 2017-07-26 13:08 ` [Qemu-devel] " Igor Mammedov 1 sibling, 2 replies; 44+ messages in thread From: Paolo Bonzini @ 2017-07-25 17:10 UTC (permalink / raw) To: Laszlo Ersek, Phil Dennis-Jordan, Igor Mammedov Cc: Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson, Gerd Hoffmann, seabios 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 ^ permalink raw reply related [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-25 17:10 ` Paolo Bonzini @ 2017-07-25 21:25 ` Phil Dennis-Jordan 2017-07-26 8:53 ` Paolo Bonzini 2017-07-25 22:01 ` [Qemu-devel] [SeaBIOS] " Kevin O'Connor 1 sibling, 1 reply; 44+ messages in thread From: Phil Dennis-Jordan @ 2017-07-25 21:25 UTC (permalink / raw) To: Paolo Bonzini Cc: Laszlo Ersek, Igor Mammedov, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson, Gerd Hoffmann, seabios 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> ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-25 21:25 ` Phil Dennis-Jordan @ 2017-07-26 8:53 ` Paolo Bonzini 2017-07-26 11:42 ` Laszlo Ersek 0 siblings, 1 reply; 44+ messages in thread From: Paolo Bonzini @ 2017-07-26 8:53 UTC (permalink / raw) To: Phil Dennis-Jordan Cc: Phil Dennis-Jordan, ehabkost, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Gerd Hoffmann, Igor Mammedov, Laszlo Ersek, Richard Henderson 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> > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-26 8:53 ` Paolo Bonzini @ 2017-07-26 11:42 ` Laszlo Ersek 2017-07-26 12:06 ` Paolo Bonzini 0 siblings, 1 reply; 44+ messages in thread From: Laszlo Ersek @ 2017-07-26 11:42 UTC (permalink / raw) To: Paolo Bonzini, Phil Dennis-Jordan Cc: Phil Dennis-Jordan, ehabkost, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Gerd Hoffmann, Igor Mammedov, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-26 11:42 ` Laszlo Ersek @ 2017-07-26 12:06 ` Paolo Bonzini 0 siblings, 0 replies; 44+ messages in thread From: Paolo Bonzini @ 2017-07-26 12:06 UTC (permalink / raw) To: Laszlo Ersek, Phil Dennis-Jordan Cc: Phil Dennis-Jordan, ehabkost, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Gerd Hoffmann, Igor Mammedov, Richard Henderson 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-25 17:10 ` Paolo Bonzini 2017-07-25 21:25 ` Phil Dennis-Jordan @ 2017-07-25 22:01 ` Kevin O'Connor 2017-07-26 7:20 ` Paolo Bonzini 1 sibling, 1 reply; 44+ messages in thread From: Kevin O'Connor @ 2017-07-25 22:01 UTC (permalink / raw) To: Paolo Bonzini Cc: Laszlo Ersek, Phil Dennis-Jordan, Igor Mammedov, Phil Dennis-Jordan, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Gerd Hoffmann, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 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 0 siblings, 1 reply; 44+ messages in thread From: Paolo Bonzini @ 2017-07-26 7:20 UTC (permalink / raw) To: Kevin O'Connor Cc: Phil Dennis-Jordan, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Gerd Hoffmann, Phil Dennis-Jordan, Igor Mammedov, Laszlo Ersek, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-26 7:20 ` Paolo Bonzini @ 2017-07-26 19:12 ` Kevin O'Connor 2017-07-26 20:21 ` Paolo Bonzini 0 siblings, 1 reply; 44+ messages in thread From: Kevin O'Connor @ 2017-07-26 19:12 UTC (permalink / raw) To: Paolo Bonzini Cc: Phil Dennis-Jordan, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Gerd Hoffmann, Phil Dennis-Jordan, Igor Mammedov, Laszlo Ersek, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 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 14:59 ` Kevin O'Connor 0 siblings, 2 replies; 44+ messages in thread From: Paolo Bonzini @ 2017-07-26 20:21 UTC (permalink / raw) To: Kevin O'Connor Cc: Phil Dennis-Jordan, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Gerd Hoffmann, Phil Dennis-Jordan, Igor Mammedov, Laszlo Ersek, Richard Henderson > > (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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 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 1 sibling, 1 reply; 44+ messages in thread From: Gerd Hoffmann @ 2017-07-27 8:39 UTC (permalink / raw) To: Paolo Bonzini, Kevin O'Connor Cc: Phil Dennis-Jordan, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Phil Dennis-Jordan, Igor Mammedov, Laszlo Ersek, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-27 8:39 ` Gerd Hoffmann @ 2017-07-27 12:26 ` Paolo Bonzini 0 siblings, 0 replies; 44+ messages in thread From: Paolo Bonzini @ 2017-07-27 12:26 UTC (permalink / raw) To: Gerd Hoffmann, Kevin O'Connor Cc: Phil Dennis-Jordan, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Phil Dennis-Jordan, Igor Mammedov, Laszlo Ersek, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-26 20:21 ` Paolo Bonzini 2017-07-27 8:39 ` Gerd Hoffmann @ 2017-07-27 14:59 ` Kevin O'Connor 2017-07-27 17:46 ` Laszlo Ersek 1 sibling, 1 reply; 44+ messages in thread From: Kevin O'Connor @ 2017-07-27 14:59 UTC (permalink / raw) To: Paolo Bonzini Cc: Phil Dennis-Jordan, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Gerd Hoffmann, Phil Dennis-Jordan, Igor Mammedov, Laszlo Ersek, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-27 14:59 ` Kevin O'Connor @ 2017-07-27 17:46 ` Laszlo Ersek 2017-07-28 6:57 ` Gerd Hoffmann 0 siblings, 1 reply; 44+ messages in thread From: Laszlo Ersek @ 2017-07-27 17:46 UTC (permalink / raw) To: Kevin O'Connor, Paolo Bonzini Cc: Phil Dennis-Jordan, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Gerd Hoffmann, Phil Dennis-Jordan, Igor Mammedov, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] [SeaBIOS] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-27 17:46 ` Laszlo Ersek @ 2017-07-28 6:57 ` Gerd Hoffmann 0 siblings, 0 replies; 44+ messages in thread From: Gerd Hoffmann @ 2017-07-28 6:57 UTC (permalink / raw) To: Laszlo Ersek, Kevin O'Connor, Paolo Bonzini Cc: Phil Dennis-Jordan, seabios, qemu-devel@nongnu.org qemu-devel, Programmingkid, Phil Dennis-Jordan, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-25 16:23 ` Paolo Bonzini 2017-07-25 17:10 ` Paolo Bonzini @ 2017-07-26 13:08 ` Igor Mammedov 2017-07-26 13:10 ` Paolo Bonzini 1 sibling, 1 reply; 44+ messages in thread From: Igor Mammedov @ 2017-07-26 13:08 UTC (permalink / raw) To: Paolo Bonzini Cc: Laszlo Ersek, Phil Dennis-Jordan, Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson 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. > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-26 13:08 ` [Qemu-devel] " Igor Mammedov @ 2017-07-26 13:10 ` Paolo Bonzini 2017-07-26 13:30 ` Igor Mammedov 0 siblings, 1 reply; 44+ messages in thread From: Paolo Bonzini @ 2017-07-26 13:10 UTC (permalink / raw) To: Igor Mammedov Cc: Laszlo Ersek, Phil Dennis-Jordan, Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson 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. >> > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 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:57 ` Michael S. Tsirkin 0 siblings, 2 replies; 44+ messages in thread From: Igor Mammedov @ 2017-07-26 13:30 UTC (permalink / raw) To: Paolo Bonzini Cc: Laszlo Ersek, Phil Dennis-Jordan, Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson, Michael S. Tsirkin 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. > >> > > > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-26 13:30 ` Igor Mammedov @ 2017-07-26 13:33 ` Paolo Bonzini 2017-07-26 13:43 ` Igor Mammedov 2017-07-26 13:57 ` Michael S. Tsirkin 1 sibling, 1 reply; 44+ messages in thread From: Paolo Bonzini @ 2017-07-26 13:33 UTC (permalink / raw) To: Igor Mammedov Cc: Laszlo Ersek, Phil Dennis-Jordan, Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson, Michael S. Tsirkin 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. >>>> >>> >> > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-26 13:33 ` Paolo Bonzini @ 2017-07-26 13:43 ` Igor Mammedov 2017-07-26 14:04 ` Daniel P. Berrange 0 siblings, 1 reply; 44+ messages in thread From: Igor Mammedov @ 2017-07-26 13:43 UTC (permalink / raw) To: Paolo Bonzini Cc: Laszlo Ersek, Phil Dennis-Jordan, Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson, Michael S. Tsirkin 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. > >>>> > >>> > >> > > > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-26 13:43 ` Igor Mammedov @ 2017-07-26 14:04 ` Daniel P. Berrange 2017-07-26 16:13 ` Michael S. Tsirkin 0 siblings, 1 reply; 44+ messages in thread From: Daniel P. Berrange @ 2017-07-26 14:04 UTC (permalink / raw) To: Igor Mammedov Cc: Paolo Bonzini, Laszlo Ersek, Phil Dennis-Jordan, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson, Michael S. Tsirkin 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 :| ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-26 14:04 ` Daniel P. Berrange @ 2017-07-26 16:13 ` Michael S. Tsirkin 0 siblings, 0 replies; 44+ messages in thread From: Michael S. Tsirkin @ 2017-07-26 16:13 UTC (permalink / raw) To: Daniel P. Berrange Cc: Igor Mammedov, Paolo Bonzini, Laszlo Ersek, Phil Dennis-Jordan, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-26 13:30 ` Igor Mammedov 2017-07-26 13:33 ` Paolo Bonzini @ 2017-07-26 13:57 ` Michael S. Tsirkin 1 sibling, 0 replies; 44+ messages in thread From: Michael S. Tsirkin @ 2017-07-26 13:57 UTC (permalink / raw) To: Igor Mammedov Cc: Paolo Bonzini, Laszlo Ersek, Phil Dennis-Jordan, Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Richard Henderson 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. > > >> > > > > > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 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-24 12:45 ` Gerd Hoffmann 2017-07-24 16:43 ` John Snow 3 siblings, 0 replies; 44+ messages in thread From: Gerd Hoffmann @ 2017-07-24 12:45 UTC (permalink / raw) To: Igor Mammedov, Phil Dennis-Jordan Cc: Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Paolo Bonzini, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-21 9:06 ` Igor Mammedov ` (2 preceding siblings ...) 2017-07-24 12:45 ` Gerd Hoffmann @ 2017-07-24 16:43 ` John Snow 2017-07-24 17:30 ` Programmingkid 3 siblings, 1 reply; 44+ messages in thread From: John Snow @ 2017-07-24 16:43 UTC (permalink / raw) To: Igor Mammedov, Phil Dennis-Jordan Cc: Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Paolo Bonzini, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-24 16:43 ` John Snow @ 2017-07-24 17:30 ` Programmingkid 0 siblings, 0 replies; 44+ messages in thread From: Programmingkid @ 2017-07-24 17:30 UTC (permalink / raw) To: John Snow Cc: Igor Mammedov, Phil Dennis-Jordan, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Paolo Bonzini, Richard Henderson > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 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:20 ` Daniel P. Berrange 2017-07-21 9:46 ` Igor Mammedov 2 siblings, 1 reply; 44+ messages in thread From: Daniel P. Berrange @ 2017-07-21 9:20 UTC (permalink / raw) To: Phil Dennis-Jordan Cc: Programmingkid, qemu-devel@nongnu.org qemu-devel, Paolo Bonzini, Phil Dennis-Jordan, ehabkost, Richard Henderson 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 :| ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-21 9:20 ` Daniel P. Berrange @ 2017-07-21 9:46 ` Igor Mammedov 2017-07-21 10:39 ` Phil Dennis-Jordan 2017-07-21 10:50 ` BALATON Zoltan 0 siblings, 2 replies; 44+ messages in thread From: Igor Mammedov @ 2017-07-21 9:46 UTC (permalink / raw) To: Daniel P. Berrange Cc: Phil Dennis-Jordan, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Paolo Bonzini, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-21 9:46 ` Igor Mammedov @ 2017-07-21 10:39 ` Phil Dennis-Jordan 2017-07-21 10:50 ` BALATON Zoltan 1 sibling, 0 replies; 44+ messages in thread From: Phil Dennis-Jordan @ 2017-07-21 10:39 UTC (permalink / raw) To: Igor Mammedov Cc: Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Paolo Bonzini, Richard Henderson 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 > ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-21 9:46 ` Igor Mammedov 2017-07-21 10:39 ` Phil Dennis-Jordan @ 2017-07-21 10:50 ` BALATON Zoltan 2017-07-21 11:46 ` Phil Dennis-Jordan 1 sibling, 1 reply; 44+ messages in thread From: BALATON Zoltan @ 2017-07-21 10:50 UTC (permalink / raw) To: Igor Mammedov Cc: Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Phil Dennis-Jordan, Paolo Bonzini, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-21 10:50 ` BALATON Zoltan @ 2017-07-21 11:46 ` Phil Dennis-Jordan 2017-07-21 17:17 ` BALATON Zoltan 0 siblings, 1 reply; 44+ messages in thread From: Phil Dennis-Jordan @ 2017-07-21 11:46 UTC (permalink / raw) To: BALATON Zoltan Cc: Igor Mammedov, Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Paolo Bonzini, Richard Henderson 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support 2017-07-21 11:46 ` Phil Dennis-Jordan @ 2017-07-21 17:17 ` BALATON Zoltan 0 siblings, 0 replies; 44+ messages in thread From: BALATON Zoltan @ 2017-07-21 17:17 UTC (permalink / raw) To: Phil Dennis-Jordan Cc: Igor Mammedov, Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, qemu-devel@nongnu.org qemu-devel, Programmingkid, Paolo Bonzini, Richard Henderson 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 ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <mailman.85963.1500629384.22737.qemu-devel@nongnu.org>]
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support [not found] <mailman.85963.1500629384.22737.qemu-devel@nongnu.org> @ 2017-07-21 16:00 ` Programmingkid 0 siblings, 0 replies; 44+ messages in thread From: Programmingkid @ 2017-07-21 16:00 UTC (permalink / raw) To: Igor Mammedov Cc: qemu-devel@nongnu.org qemu-devel, Paolo Bonzini, Phil Dennis-Jordan, ehabkost, Richard Henderson > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
[parent not found: <mailman.86860.1501079288.22738.qemu-devel@nongnu.org>]
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support [not found] <mailman.86860.1501079288.22738.qemu-devel@nongnu.org> @ 2017-07-27 2:38 ` Programmingkid 0 siblings, 0 replies; 44+ messages in thread From: Programmingkid @ 2017-07-27 2:38 UTC (permalink / raw) To: Igor Mammedov Cc: qemu-devel@nongnu.org qemu-devel, Paolo Bonzini, Laszlo Ersek, Phil Dennis-Jordan, Daniel P. Berrange, Phil Dennis-Jordan, ehabkost, Programmingkid, Richard Henderson, Michael S. Tsirkin > 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. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support @ 2017-07-27 3:23 Programmingkid 0 siblings, 0 replies; 44+ messages in thread From: Programmingkid @ 2017-07-27 3:23 UTC (permalink / raw) To: qemu-devel@nongnu.org qemu-devel Cc: Laszlo Ersek, Paolo Bonzini, Phil Dennis-Jordan, ehabkost, Programmingkid, Gerd Hoffmann, Igor Mammedov, Richard Henderson, seabios 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? ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2017-07-28 6:57 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.