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/
Home Products Support Community News


RE: [Xen-devel] cpu_down() but no cpu_up() in drivers/xen/cpu_hotplug.c

To: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: RE: [Xen-devel] cpu_down() but no cpu_up() in drivers/xen/cpu_hotplug.c ?
From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Date: Wed, 12 May 2010 11:25:49 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Jan, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Tue, 11 May 2010 20:28:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4BE9967F.7080409@xxxxxxxx>
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: <4BE940C80200007800002410@xxxxxxxxxxxxxxxxxx> <1273571127.7572.2905.camel@xxxxxxxxxxxxxxxxxxxxxx> <4BE9967F.7080409@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcrxMSbkAxmrsKnWQ4Wuys+yla65SgAUNtdQ
Thread-topic: [Xen-devel] cpu_down() but no cpu_up() in drivers/xen/cpu_hotplug.c ?

>-----Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jeremy Fitzhardinge
>Sent: Wednesday, May 12, 2010 1:40 AM
>To: Ian Campbell
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Jan Beulich
>Subject: Re: [Xen-devel] cpu_down() but no cpu_up() in 
>drivers/xen/cpu_hotplug.c ?
>On 05/11/2010 02:45 AM, Ian Campbell wrote:
>> The original commit which added CPU hotplug to pvops says:
>>     xen: implement CPU hotplugging
>>     Note the changes from 2.6.18-xen CPU hotplugging:
>>     A vcpu_down request from the remote admin via Xenbus both hotunplugs the
>>     CPU, and disables it by removing it from the cpu_present map, and 
>> removing
>>     its entry in /sys.
>>     A vcpu_up request from the remote admin only re-enables the CPU, and does
>>     not immediately bring the CPU up. A udev event is emitted, which can be
>>     caught by the user if he wishes to automatically re-up CPUs when 
>> available,
>>     or implement a more complex policy.
>>     Signed-off-by: Alex Nixon <alex.nixon@xxxxxxxxxx>
>>     Acked-by: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
>>     Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
>> I'm not sure how the decision was reached to implement it this way,
>> perhaps for consistency with CPU hotplug on other
>> platforms/architectures?
>Yes, it was to make it consistent with native physical CPU hotplug.  It
>also replaced some other xen-specific mechanism to allow the domain to
>control when the cpu was actually added (I forget the details; something
>like "cpus allowed" vs "cpus active" or something?).

I remember for cpu remove, the xen's vcpu is different to native method. In 
native, it will only trigger a uevent to user space (at least in version like 
2.6.31), while for xen vcpu, it will remove the vcpu directly.


>> FWIW I use a udev rule to bring up CPUs as they are added, which is
>> equivalent to the old behaviour:
>>         ACTION=="add", SUBSYSTEM=="cpu", RUN+="/bin/sh -c '[ ! -e
>/sys$devpath/online ] || echo 1 > /sys$devpath/online'"
>Fedora and RHEL have been shipping with something like this for a while.
>    J
>Xen-devel mailing list
Xen-devel mailing list