Re: [PATCH] Set bit 1 in disabled processor's _STA
On Sun, May 17, 2009 at 12:47:03PM -0300, Glauber Costa wrote: I admitedly know almost nothing about windows, but one thing jumped to my eyes: By looking at the device manager, hidden devices, the working cpu seems to be cpu1, not cpu0. Maybe this is related to this problem? I think this is just peculiarity of a device manager GUI. For me it shows CPUs in the order: 10-14 0-9 so working CPU appears to be fifth on the cpu list. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Mon, May 18, 2009 at 08:53:58AM +0300, Gleb Natapov wrote: On Mon, May 18, 2009 at 08:44:54AM +0300, Avi Kivity wrote: Gleb Natapov wrote: On Sun, May 17, 2009 at 11:07:31PM +0300, Avi Kivity wrote: Gleb Natapov wrote: Theoretically we can provide different values for different OSes, but this is just a guess work since there is no any documentation how CPU hot-plug should work on x86. ACPI in fact supports this, but I hope we don't have to do that. ACPI way is what I am talking about. Implement _OS object. /* * The story of _OSI(Linux) * * From pre-history through Linux-2.6.22, * Linux responded TRUE upon a BIOS OSI(Linux) query. * * Unfortunately, reference BIOS writers got wind of this * and put OSI(Linux) in their example code, quickly exposing * this string as ill-conceived and opening the door to * an un-bounded number of BIOS incompatibilities. * * For example, OSI(Linux) was used on resume to re-POST a * video card on one system, because Linux at that time * could not do a speedy restore in its native driver. * But then upon gaining quick native restore capability, * Linux has no way to tell the BIOS to skip the time-consuming * POST -- putting Linux at a permanent performance disadvantage. * On another system, the BIOS writer used OSI(Linux) * to infer native OS support for IPMI! On other systems, * OSI(Linux) simply got in the way of Linux claiming to * be compatible with other operating systems, exposing * BIOS issues such as skipped device initialization. * * So Linux turned out to be a really poor chose of * OSI string, and from Linux-2.6.23 onward we respond FALSE. * * BIOS writers should NOT query _OSI(Linux) on future systems. * Linux will complain on the console when it sees it, and return FALSE. * To get Linux to return TRUE for your system will require * a kernel source update to add a DMI entry, * or boot with acpi_osi=Linux */ // Looks like no real content in this message? Now I recall something on LKML about this. Well, in this case Linux shouldn't have used ACPI to invent its own way to do cpu hot-plug. It didn't. History shows that this method is what is used in some unisys machines, which seems to be the only ones implementing this around. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Mon, May 18, 2009 at 08:39:43AM -0300, Glauber Costa wrote: Now I recall something on LKML about this. Well, in this case Linux shouldn't have used ACPI to invent its own way to do cpu hot-plug. It didn't. History shows that this method is what is used in some unisys machines, which seems to be the only ones implementing this around. The questions are: What is this that linux currently implements, how windows expects CPU hot-plug to work, are there any real x86 hardware that supports CPU host-plug and what should we do about all this. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Mon, May 18, 2009 at 02:40:18PM +0300, Gleb Natapov wrote: On Mon, May 18, 2009 at 08:39:43AM -0300, Glauber Costa wrote: Now I recall something on LKML about this. Well, in this case Linux shouldn't have used ACPI to invent its own way to do cpu hot-plug. It didn't. History shows that this method is what is used in some unisys machines, which seems to be the only ones implementing this around. The questions are: What is this that linux currently implements, how windows expects CPU hot-plug to work, are there any real x86 hardware that supports CPU host-plug and what should we do about all this. as I said, there are unisys machines that implements cpu hotplug. The way they do it, is the way Linux kernel currently expects. The same way we implement on our BIOS. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Mon, May 18, 2009 at 09:40:03AM -0300, Glauber Costa wrote: On Mon, May 18, 2009 at 02:40:18PM +0300, Gleb Natapov wrote: On Mon, May 18, 2009 at 08:39:43AM -0300, Glauber Costa wrote: Now I recall something on LKML about this. Well, in this case Linux shouldn't have used ACPI to invent its own way to do cpu hot-plug. It didn't. History shows that this method is what is used in some unisys machines, which seems to be the only ones implementing this around. The questions are: What is this that linux currently implements, how windows expects CPU hot-plug to work, are there any real x86 hardware that supports CPU host-plug and what should we do about all this. as I said, there are unisys machines that implements cpu hotplug. The way they do it, is the way Linux kernel currently expects. The same way we implement on our BIOS. I read that document too. And based on some input from Natalie of Unisys does not sound promising. Are those Unisys machines certified to run Windows 2008? Because if they are, they surely do something different from what we are doing. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Mon, May 18, 2009 at 03:42:10PM +0300, Gleb Natapov wrote: On Mon, May 18, 2009 at 09:40:03AM -0300, Glauber Costa wrote: On Mon, May 18, 2009 at 02:40:18PM +0300, Gleb Natapov wrote: On Mon, May 18, 2009 at 08:39:43AM -0300, Glauber Costa wrote: Now I recall something on LKML about this. Well, in this case Linux shouldn't have used ACPI to invent its own way to do cpu hot-plug. It didn't. History shows that this method is what is used in some unisys machines, which seems to be the only ones implementing this around. The questions are: What is this that linux currently implements, how windows expects CPU hot-plug to work, are there any real x86 hardware that supports CPU host-plug and what should we do about all this. as I said, there are unisys machines that implements cpu hotplug. The way they do it, is the way Linux kernel currently expects. The same way we implement on our BIOS. I read that document too. And based on some input from Natalie of Unisys does not sound promising. I'm not saying it is promising. Nothing un-specified is. Google search for the mails exchanged on the time of development of this also point in the direction that this is probably all we have. Are those Unisys machines certified to run Windows 2008? Because if they are, they surely do something different from what we are doing. Unless they have a time machine, it is unlikely. Windows 2008 did not exist at the time -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Fri, May 15, 2009 at 08:14:43AM -0400, Glauber Costa wrote:
This patch sets bits 1 in disabled processor's _STA.
According to the ACPI spec, this bit means:
Set if the device is enabled and decoding its resources.
Without it, Windows 2008 device manager shows the processors
as malfunctioning hardware.
If you uncheck show hidden devices option in View menu of the
device manager you should see only enabled CPUs (bit 2 of _STA).
This patch breaks resume from hibernate on windows 2008/vista.
Signed-off-by: Glauber Costa glom...@redhat.com
---
kvm/bios/acpi-dsdt.dsl |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kvm/bios/acpi-dsdt.dsl b/kvm/bios/acpi-dsdt.dsl
index c756fed..c53816c 100755
--- a/kvm/bios/acpi-dsdt.dsl
+++ b/kvm/bios/acpi-dsdt.dsl
@@ -56,7 +56,7 @@ DefinitionBlock (
} \
Method (_STA) { \
If (CRST(nr)) { Return(0xF) } \
-Else { Return(0x9) }\
+Else { Return(0xB) }\
} \
} \
--
1.5.6.6
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Sun, May 17, 2009 at 11:23:47AM +0300, Gleb Natapov wrote: On Fri, May 15, 2009 at 08:14:43AM -0400, Glauber Costa wrote: This patch sets bits 1 in disabled processor's _STA. According to the ACPI spec, this bit means: Set if the device is enabled and decoding its resources. Without it, Windows 2008 device manager shows the processors as malfunctioning hardware. If you uncheck show hidden devices option in View menu of the device manager you should see only enabled CPUs (bit 2 of _STA). Yes, that is what happens. But then, by checking show hidden devices, the disabled processor appears, but are listed as malfunctioning. Because of this, SVVP tests break without this patch. This patch breaks resume from hibernate on windows 2008/vista. Oh god... do you have any idea why? which bits should we set for everything to work? It appears to me that having bit 2 cleared should do the right thing, but your test clearly indicate otherwise. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Sun, May 17, 2009 at 10:27:41AM -0300, Glauber Costa wrote: On Sun, May 17, 2009 at 11:23:47AM +0300, Gleb Natapov wrote: On Fri, May 15, 2009 at 08:14:43AM -0400, Glauber Costa wrote: This patch sets bits 1 in disabled processor's _STA. According to the ACPI spec, this bit means: Set if the device is enabled and decoding its resources. Without it, Windows 2008 device manager shows the processors as malfunctioning hardware. If you uncheck show hidden devices option in View menu of the device manager you should see only enabled CPUs (bit 2 of _STA). Yes, that is what happens. But then, by checking show hidden devices, the disabled processor appears, but are listed as malfunctioning. Because of this, SVVP tests break without this patch. What kind of error? This patch breaks resume from hibernate on windows 2008/vista. Oh god... do you have any idea why? which bits should we set for everything to work? Bit 1 should not be set :) What I think is happening windows finds more CPUs on resume then it had before hibernate. It appears to me that having bit 2 cleared should do the right thing, but your test clearly indicate otherwise. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Sun, May 17, 2009 at 11:31:07AM -0300, Glauber Costa wrote: On Sun, May 17, 2009 at 11:23:47AM +0300, Gleb Natapov wrote: On Fri, May 15, 2009 at 08:14:43AM -0400, Glauber Costa wrote: This patch sets bits 1 in disabled processor's _STA. According to the ACPI spec, this bit means: Set if the device is enabled and decoding its resources. Without it, Windows 2008 device manager shows the processors as malfunctioning hardware. If you uncheck show hidden devices option in View menu of the device manager you should see only enabled CPUs (bit 2 of _STA). This patch breaks resume from hibernate on windows 2008/vista. The last change on that piece of code was made by you under the comment: 1) Disabled processor's _STA method should return 0 (this fixes Vista's BSOD on resuming after hibernate problem) However, you did not changed it to 0, but to 9 instead. What did you meant? I wrote commit message before changing it to 9 :( I don't remember why I changed it to 9, but I think it was because of Linux CPU hot-plug. It appears that windows won't accept bit 0 without bit 1 being set. However, it works fine in my use case if _STA returns 0 or 8. The only real problem is, as I said, setting bit 0 but not bit 1. Does any among 0 or 8 works for your hibernate use case? Can you check Linux cpu hot-plug please. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Sun, May 17, 2009 at 05:30:06PM +0300, Gleb Natapov wrote: On Sun, May 17, 2009 at 10:27:41AM -0300, Glauber Costa wrote: On Sun, May 17, 2009 at 11:23:47AM +0300, Gleb Natapov wrote: On Fri, May 15, 2009 at 08:14:43AM -0400, Glauber Costa wrote: This patch sets bits 1 in disabled processor's _STA. According to the ACPI spec, this bit means: Set if the device is enabled and decoding its resources. Without it, Windows 2008 device manager shows the processors as malfunctioning hardware. If you uncheck show hidden devices option in View menu of the device manager you should see only enabled CPUs (bit 2 of _STA). Yes, that is what happens. But then, by checking show hidden devices, the disabled processor appears, but are listed as malfunctioning. Because of this, SVVP tests break without this patch. What kind of error? Message 4/15/2009 4:07:04.635 AM Checking Intel Processor Error 4/15/2009 4:07:04.635 AM ERROR: Device (QEMU Virtual CPU version 0.9.1) is not currently enabled, or has some problem File:Line: 0 Error Type: BOOL Error Code: 0x1 Error Text: Error 0x0001 Alternatively, if you go to the device manager, and Show hidden processors, you'll see the processors appear, but marked with a !. Clicking into details, there is a message saying that the device is malfunctioning. This patch breaks resume from hibernate on windows 2008/vista. Oh god... do you have any idea why? which bits should we set for everything to work? Bit 1 should not be set :) What I think is happening windows finds more CPUs on resume then it had before hibernate. It does not make sense to me at first. resume should not be a much different use case than plain boot. If it does the right thing on bootup, why would it mess up in case of resume? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Sun, May 17, 2009 at 05:32:35PM +0300, Gleb Natapov wrote: On Sun, May 17, 2009 at 11:31:07AM -0300, Glauber Costa wrote: On Sun, May 17, 2009 at 11:23:47AM +0300, Gleb Natapov wrote: On Fri, May 15, 2009 at 08:14:43AM -0400, Glauber Costa wrote: This patch sets bits 1 in disabled processor's _STA. According to the ACPI spec, this bit means: Set if the device is enabled and decoding its resources. Without it, Windows 2008 device manager shows the processors as malfunctioning hardware. If you uncheck show hidden devices option in View menu of the device manager you should see only enabled CPUs (bit 2 of _STA). This patch breaks resume from hibernate on windows 2008/vista. The last change on that piece of code was made by you under the comment: 1) Disabled processor's _STA method should return 0 (this fixes Vista's BSOD on resuming after hibernate problem) However, you did not changed it to 0, but to 9 instead. What did you meant? I wrote commit message before changing it to 9 :( I don't remember why I changed it to 9, but I think it was because of Linux CPU hot-plug. It appears that windows won't accept bit 0 without bit 1 being set. However, it works fine in my use case if _STA returns 0 or 8. The only real problem is, as I said, setting bit 0 but not bit 1. Does any among 0 or 8 works for your hibernate use case? Can you check Linux cpu hot-plug please. Yeah, unfortunately neither work for linux cpu hotplug. Anything without bit 0 set won't work. So valid values appear to be 0x1, 0x3, 0x9, 0xB. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Sun, May 17, 2009 at 12:06:22PM -0300, Glauber Costa wrote: On Sun, May 17, 2009 at 05:30:06PM +0300, Gleb Natapov wrote: On Sun, May 17, 2009 at 10:27:41AM -0300, Glauber Costa wrote: On Sun, May 17, 2009 at 11:23:47AM +0300, Gleb Natapov wrote: On Fri, May 15, 2009 at 08:14:43AM -0400, Glauber Costa wrote: This patch sets bits 1 in disabled processor's _STA. According to the ACPI spec, this bit means: Set if the device is enabled and decoding its resources. Without it, Windows 2008 device manager shows the processors as malfunctioning hardware. If you uncheck show hidden devices option in View menu of the device manager you should see only enabled CPUs (bit 2 of _STA). Yes, that is what happens. But then, by checking show hidden devices, the disabled processor appears, but are listed as malfunctioning. Because of this, SVVP tests break without this patch. What kind of error? Message 4/15/2009 4:07:04.635 AM Checking Intel Processor Error 4/15/2009 4:07:04.635 AM ERROR: Device (QEMU Virtual CPU version 0.9.1) is not currently enabled, or has some problem File:Line: 0 Error Type: BOOL Error Code: 0x1 Error Text: Error 0x0001 Alternatively, if you go to the device manager, and Show hidden processors, you'll see the processors appear, but marked with a !. Clicking into details, there is a message saying that the device is malfunctioning. This patch breaks resume from hibernate on windows 2008/vista. Oh god... do you have any idea why? which bits should we set for everything to work? Bit 1 should not be set :) What I think is happening windows finds more CPUs on resume then it had before hibernate. It does not make sense to me at first. resume should not be a much different use case than plain boot. If it does the right thing on bootup, why would it mess up in case of resume? I wish I had an answer to this. It may be a bug. On boot windows calculates number of processors from madt tables, but on resume it does the same by executing _STA method of each defined CPU. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Sun, May 17, 2009 at 12:07:27PM -0300, Glauber Costa wrote: On Sun, May 17, 2009 at 05:32:35PM +0300, Gleb Natapov wrote: On Sun, May 17, 2009 at 11:31:07AM -0300, Glauber Costa wrote: On Sun, May 17, 2009 at 11:23:47AM +0300, Gleb Natapov wrote: On Fri, May 15, 2009 at 08:14:43AM -0400, Glauber Costa wrote: This patch sets bits 1 in disabled processor's _STA. According to the ACPI spec, this bit means: Set if the device is enabled and decoding its resources. Without it, Windows 2008 device manager shows the processors as malfunctioning hardware. If you uncheck show hidden devices option in View menu of the device manager you should see only enabled CPUs (bit 2 of _STA). This patch breaks resume from hibernate on windows 2008/vista. The last change on that piece of code was made by you under the comment: 1) Disabled processor's _STA method should return 0 (this fixes Vista's BSOD on resuming after hibernate problem) However, you did not changed it to 0, but to 9 instead. What did you meant? I wrote commit message before changing it to 9 :( I don't remember why I changed it to 9, but I think it was because of Linux CPU hot-plug. It appears that windows won't accept bit 0 without bit 1 being set. However, it works fine in my use case if _STA returns 0 or 8. The only real problem is, as I said, setting bit 0 but not bit 1. Does any among 0 or 8 works for your hibernate use case? Can you check Linux cpu hot-plug please. Yeah, unfortunately neither work for linux cpu hotplug. Anything without bit 0 set won't work. So valid values appear to be 0x1, 0x3, 0x9, 0xB. Theoretically we can provide different values for different OSes, but this is just a guess work since there is no any documentation how CPU hot-plug should work on x86. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Sun, May 17, 2009 at 06:21:45PM +0300, Gleb Natapov wrote: On Sun, May 17, 2009 at 12:06:22PM -0300, Glauber Costa wrote: On Sun, May 17, 2009 at 05:30:06PM +0300, Gleb Natapov wrote: On Sun, May 17, 2009 at 10:27:41AM -0300, Glauber Costa wrote: On Sun, May 17, 2009 at 11:23:47AM +0300, Gleb Natapov wrote: On Fri, May 15, 2009 at 08:14:43AM -0400, Glauber Costa wrote: This patch sets bits 1 in disabled processor's _STA. According to the ACPI spec, this bit means: Set if the device is enabled and decoding its resources. Without it, Windows 2008 device manager shows the processors as malfunctioning hardware. If you uncheck show hidden devices option in View menu of the device manager you should see only enabled CPUs (bit 2 of _STA). Yes, that is what happens. But then, by checking show hidden devices, the disabled processor appears, but are listed as malfunctioning. Because of this, SVVP tests break without this patch. What kind of error? Message 4/15/2009 4:07:04.635 AM Checking Intel Processor Error 4/15/2009 4:07:04.635 AM ERROR: Device (QEMU Virtual CPU version 0.9.1) is not currently enabled, or has some problem File:Line: 0 Error Type: BOOL Error Code: 0x1 Error Text: Error 0x0001 Alternatively, if you go to the device manager, and Show hidden processors, you'll see the processors appear, but marked with a !. Clicking into details, there is a message saying that the device is malfunctioning. This patch breaks resume from hibernate on windows 2008/vista. Oh god... do you have any idea why? which bits should we set for everything to work? Bit 1 should not be set :) What I think is happening windows finds more CPUs on resume then it had before hibernate. It does not make sense to me at first. resume should not be a much different use case than plain boot. If it does the right thing on bootup, why would it mess up in case of resume? I wish I had an answer to this. It may be a bug. On boot windows calculates number of processors from madt tables, but on resume it does the same by executing _STA method of each defined CPU. I admitedly know almost nothing about windows, but one thing jumped to my eyes: By looking at the device manager, hidden devices, the working cpu seems to be cpu1, not cpu0. Maybe this is related to this problem? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
Gleb Natapov wrote: Theoretically we can provide different values for different OSes, but this is just a guess work since there is no any documentation how CPU hot-plug should work on x86. ACPI in fact supports this, but I hope we don't have to do that. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Sun, May 17, 2009 at 11:07:31PM +0300, Avi Kivity wrote: Gleb Natapov wrote: Theoretically we can provide different values for different OSes, but this is just a guess work since there is no any documentation how CPU hot-plug should work on x86. ACPI in fact supports this, but I hope we don't have to do that. ACPI way is what I am talking about. Implement _OS object. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
Gleb Natapov wrote: On Sun, May 17, 2009 at 11:07:31PM +0300, Avi Kivity wrote: Gleb Natapov wrote: Theoretically we can provide different values for different OSes, but this is just a guess work since there is no any documentation how CPU hot-plug should work on x86. ACPI in fact supports this, but I hope we don't have to do that. ACPI way is what I am talking about. Implement _OS object. /* * The story of _OSI(Linux) * * From pre-history through Linux-2.6.22, * Linux responded TRUE upon a BIOS OSI(Linux) query. * * Unfortunately, reference BIOS writers got wind of this * and put OSI(Linux) in their example code, quickly exposing * this string as ill-conceived and opening the door to * an un-bounded number of BIOS incompatibilities. * * For example, OSI(Linux) was used on resume to re-POST a * video card on one system, because Linux at that time * could not do a speedy restore in its native driver. * But then upon gaining quick native restore capability, * Linux has no way to tell the BIOS to skip the time-consuming * POST -- putting Linux at a permanent performance disadvantage. * On another system, the BIOS writer used OSI(Linux) * to infer native OS support for IPMI! On other systems, * OSI(Linux) simply got in the way of Linux claiming to * be compatible with other operating systems, exposing * BIOS issues such as skipped device initialization. * * So Linux turned out to be a really poor chose of * OSI string, and from Linux-2.6.23 onward we respond FALSE. * * BIOS writers should NOT query _OSI(Linux) on future systems. * Linux will complain on the console when it sees it, and return FALSE. * To get Linux to return TRUE for your system will require * a kernel source update to add a DMI entry, * or boot with acpi_osi=Linux */ // Looks like no real content in this message? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Set bit 1 in disabled processor's _STA
On Mon, May 18, 2009 at 08:44:54AM +0300, Avi Kivity wrote: Gleb Natapov wrote: On Sun, May 17, 2009 at 11:07:31PM +0300, Avi Kivity wrote: Gleb Natapov wrote: Theoretically we can provide different values for different OSes, but this is just a guess work since there is no any documentation how CPU hot-plug should work on x86. ACPI in fact supports this, but I hope we don't have to do that. ACPI way is what I am talking about. Implement _OS object. /* * The story of _OSI(Linux) * * From pre-history through Linux-2.6.22, * Linux responded TRUE upon a BIOS OSI(Linux) query. * * Unfortunately, reference BIOS writers got wind of this * and put OSI(Linux) in their example code, quickly exposing * this string as ill-conceived and opening the door to * an un-bounded number of BIOS incompatibilities. * * For example, OSI(Linux) was used on resume to re-POST a * video card on one system, because Linux at that time * could not do a speedy restore in its native driver. * But then upon gaining quick native restore capability, * Linux has no way to tell the BIOS to skip the time-consuming * POST -- putting Linux at a permanent performance disadvantage. * On another system, the BIOS writer used OSI(Linux) * to infer native OS support for IPMI! On other systems, * OSI(Linux) simply got in the way of Linux claiming to * be compatible with other operating systems, exposing * BIOS issues such as skipped device initialization. * * So Linux turned out to be a really poor chose of * OSI string, and from Linux-2.6.23 onward we respond FALSE. * * BIOS writers should NOT query _OSI(Linux) on future systems. * Linux will complain on the console when it sees it, and return FALSE. * To get Linux to return TRUE for your system will require * a kernel source update to add a DMI entry, * or boot with acpi_osi=Linux */ // Looks like no real content in this message? Now I recall something on LKML about this. Well, in this case Linux shouldn't have used ACPI to invent its own way to do cpu hot-plug. Interesting whether _OSI(Windows) will evaluate to TRUE on Linux. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Set bit 1 in disabled processor's _STA
This patch sets bits 1 in disabled processor's _STA.
According to the ACPI spec, this bit means:
Set if the device is enabled and decoding its resources.
Without it, Windows 2008 device manager shows the processors
as malfunctioning hardware.
Signed-off-by: Glauber Costa glom...@redhat.com
---
kvm/bios/acpi-dsdt.dsl |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kvm/bios/acpi-dsdt.dsl b/kvm/bios/acpi-dsdt.dsl
index c756fed..c53816c 100755
--- a/kvm/bios/acpi-dsdt.dsl
+++ b/kvm/bios/acpi-dsdt.dsl
@@ -56,7 +56,7 @@ DefinitionBlock (
} \
Method (_STA) { \
If (CRST(nr)) { Return(0xF) } \
-Else { Return(0x9) }\
+Else { Return(0xB) }\
} \
} \
--
1.5.6.6
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
