[PATCH] Set bit 1 in disabled processor's _STA

[PATCH] Set bit 1 in disabled processor's _STA

[Glauber Costa]

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 <glommer@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

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Gleb Natapov]

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 <glommer@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
			Gleb.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Glauber Costa]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Gleb Natapov]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Glauber Costa]

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 0x00000001 

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?

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Gleb Natapov]

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

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Glauber Costa]

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 0x00000001 
> > 
> > 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?

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Gleb Natapov]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Glauber Costa]

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?

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?

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Gleb Natapov]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Glauber Costa]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Gleb Natapov]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Avi Kivity]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Glauber Costa]

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.
I believe it actually makes sense. It may even ease the acception into upstream projects.
Note that cpu hotplug is totally non specified by ACPI. This implementation is "what linux
expects", and does not work on windows at all (and I imagine it may not work on other OSes
as well). For this case, it might make sense to provide different values for different OSes.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Gleb Natapov]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Avi Kivity]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Gleb Natapov]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Glauber Costa]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Gleb Natapov]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Glauber Costa]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Gleb Natapov]

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.

Re: [PATCH] Set bit 1 in disabled processor's _STA

[Glauber Costa]

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