WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] RE: [PATCH 1/2] Vcpu hotplug: Move ACPI processor from \

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] RE: [PATCH 1/2] Vcpu hotplug: Move ACPI processor from \_PR to \_SB
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Fri, 12 Feb 2010 17:25:54 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc:
Delivery-date: Fri, 12 Feb 2010 01:26:13 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C79AC212.9EAA%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C8EDE645B81E5141A8C6B2F73FD926511BA551B8DB@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C79AC212.9EAA%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqrQRdRK42tFnx6Rbij20ZBPcBQRQACAINSAA4+mEAADuDBxwAARQvQ
Thread-topic: [Xen-devel] RE: [PATCH 1/2] Vcpu hotplug: Move ACPI processor from \_PR to \_SB

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
>Sent: Friday, February 12, 2010 4:30 PM
>To: Jiang, Yunhong; Liu, Jinsong; xen-devel
>Subject: Re: [Xen-devel] RE: [PATCH 1/2] Vcpu hotplug: Move ACPI processor from
>\_PR to \_SB
>
>On 12/02/2010 02:57, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote:
>
>> However, according to ACPI spec, the _PR is for ACPI1.0 compatible. We have 
>> no
>> idea which OS is ACPI 1.0 OS. As HeQing found ACPI 1.0 bugs in Win2K, so we
>> assume W2K is ACPI 1.0. We test shows W2K guest is ok with the _SB definition
>> in our testing. Maybe Win98/WinMe is ACPI 1.0, but we have no image for these
>> OS. But yes, that's a main issue for _SB method and we need more 
>> consideration
>> here.
>>
>> In fact, we have internal argue to choose _PR or _SB method before Jinsong's
>> initial patch sent out. Later _PR method is chosen because of the ACPI 1.0
>> compatible benifit, and kernel 30 version is ok. (IIRC, .32 kernel is not
>> released at that time).
>
>Well, that's tricky. 2.6.32 is supposed to be a long-term maintained kernel,
>so presumably there will be a 2.6.32.x along in the not-too-far future which
>fixes this Linux bug? I feel we're a bit close to the wire to make this
>change now.

We talked this issue with our colleague working on kernel side. As one key 
engineer is on vocation, I will get more information when he is back after 
Chinese New Year. 
But I'm not sure of Win2K8.

>
>I'd be a bit more comfortable if we had the cover of lots of other modern
>systems putting their processor objects under \_SB, but actually I've never
>seen one. Then again I haven't been looking at high-end systems supporting
>CPU hotplug and the like.

Yes. I only saw \_SB definition in system supporting CPU hotplug. In fact, in 
that system, the processor is defined under an container object in \_SB. As 
currently all system in our lab is shutdown for CNY, I can't find more system 
to check. And I suspect that we need care \_PR soluation, legacy OS support is 
an important usage model for virtualization.

One thing I noticed in my system is, there is a ACPI version option in my 
desktop system, and I remember I saw that option in other system also. So one 
possible solution is, place all processor definition under a seperated SSDT 
file. An option is provided so that build.c can select different SSDT based on 
user's input. But that make thing tricky still.

--jyh

>
> -- Keir
>
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel