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] cpu_down() but no cpu_up() in drivers/xen/cpu_hotplug.c

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] cpu_down() but no cpu_up() in drivers/xen/cpu_hotplug.c ?
From: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>
Date: Tue, 11 May 2010 13:30:14 +0200
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Tue, 11 May 2010 04:31:09 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=dietmar.hahn@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1273577540; x=1305113540; h=from:to:subject:date:cc:references:in-reply-to: mime-version:content-transfer-encoding:message-id; z=From:=20Dietmar=20Hahn=20<dietmar.hahn@xxxxxxxxxxxxxx> |To:=20xen-devel@xxxxxxxxxxxxxxxxxxx|Subject:=20Re:=20[Xe n-devel]=20cpu_down()=20but=20no=20cpu_up()=20in=20driver s/xen/cpu_hotplug.c=20?|Date:=20Tue,=2011=20May=202010=20 13:30:14=20+0200|Cc:=20Ian=20Campbell=20<Ian.Campbell@cit rix.com>,=0D=0A=20Jan=20Beulich=20<JBeulich@xxxxxxxxxx>, =0D=0A=20Jeremy=20Fitzhardinge=20<jeremy@xxxxxxxx> |References:=20<4BE940C80200007800002410@xxxxxxxxxxxxxxxx om>=20<1273571127.7572.2905.camel@xxxxxxxxxxxxxxxxxxxxxx> |In-Reply-To:=20<1273571127.7572.2905.camel@xxxxxxxxxxxxx ource.com>|MIME-Version:=201.0|Content-Transfer-Encoding: =207bit|Message-Id:=20<201005111330.14929.dietmar.hahn@ts .fujitsu.com>; bh=N97HgGxPqmeaXlTSnO1GBa76M8efZcfql/fPZ6bH9X8=; b=lYBCCnby1MaZnq3gxV1FySN7/9tHOtJ7x1hEVfIzPHL4j9rSTdaE51H1 fT4cI3J7Thmr6lRZFol94eycNBodQkUOt1biPClxuXgW7AYdIZvpWN/6i HXDWgURQbnDFPywF00YgGEmgOILPhBWIXqfJoqZc49xPpMbgtI97cTtKB 0EVBdqR5ezHtcYlXX5Wi2lEF2P2Yp6x/L6kKVYYnyfWwtC3OK94aJt5Y8 z+q6qOYYDGA+n4RjOVHomYywZBb40;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:From:To:Subject:Date:User-Agent:Cc: References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Message-Id; b=fNjkXwqoUInBnPQTNwu868XmB9BzinPVuDS+QIQsG1SX/3j76mPJtN4O r4PSp6pHkYhna2qQIyLkUFxj83YMVpgnxCWpgRdMFiptZ6L/u1mEIuk0M 0RnLsy3nVDkFIEOgXGAjcXqQ7lsx21vfj8P+on3sH6pq2MNZLbvQ095nV kXkwZzgK6uM2bFHpnUmb92poajidh6FC7xV/eDp/vaNzHaWzYNq0btXfI vXWqH+DhqAzG8J5tEiSsow/7I+1p6;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1273571127.7572.2905.camel@xxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.13.3 (Linux/2.6.31.13-xen-hahn; KDE/4.4.3; x86_64; ; )
Am 11.05.2010 schrieb Ian Campbell:
> On Tue, 2010-05-11 at 10:34 +0100, Jan Beulich wrote:
> > Jeremy,
> > 
> > how is pv-ops bringing up CPUs set to online in xenstore? Is this not
> > an automatic process (i.e. requires writing to respective online node
> > in sysfs), like in the traditional tree?
> 
> 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?
> 
> 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'"
> 
> Ian.

Maybe it would be good then to have a comment somewhere in the tree with
this udev rule as a hint?
Thanks.

Dietmar.

-- 
Company details: http://ts.fujitsu.com/imprint.html

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