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] [PATCH] qemu-xen: fix cpu hotplug

To: Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] qemu-xen: fix cpu hotplug
From: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
Date: Fri, 3 Sep 2010 15:47:07 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, "Li, Xin" <xin.li@xxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Fri, 03 Sep 2010 00:48:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201009030934.03106.Christoph.Egger@xxxxxxx>
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: <alpine.DEB.2.00.1009021416500.2714@kaball-desktop> <19583.57113.276530.834290@xxxxxxxxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E1837FFC067@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <201009030934.03106.Christoph.Egger@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActLOpL9hRwR4rSiS/a9BkC/gEj9GgAAWsrg
Thread-topic: [Xen-devel] [PATCH] qemu-xen: fix cpu hotplug
Christoph Egger wrote:
> On Friday 03 September 2010 08:28:53 Liu, Jinsong wrote:
>> Ian Jackson wrote:
>>> Stefano Stabellini writes ("[Xen-devel] [PATCH] qemu-xen: fix cpu
>>> hotplug"):
>>>> qemu-xen: fix cpu hotplug
>>>> The current xenstore watch path for a vcpu-set event is wrong and
>>>> is also wrong the code to parse it.  This patch fixes both of them:
>>> Thanks.  So it seems you're saying it's completely broken in
>>> xen-unstable.
>> Stabellini, I read your attached patch, it's OK.
>> In fact, we firstly implemented xenstore watch by same scheme of your
>> patch, watching each cpu node status:
>> /local/domain/xx/cpu/yy/availability=offline (online)
>> However, we finally didn't use this scheme. We watch 'common' node
>> instead: /local/domain/xx/cpu in this way, only 1 watch point need.
>> Considering vcpu number may become more and more in the future (say,
>> more than 128), it's more simple and reasonable. (Watches can be set
>> at points in the hierarchy and an individual watch will be triggered
>> when anything at or below that point in the hierachy changes)
> Does this scheme allow to say how many cores per cpu exist ?
> When you run a Windows guest with a license for one cpu socket,
> then you can use 4 cores. But if one cpu is equal to one socket,
> then you can't use SMP for the Windows guest.
> Christoph

Seems this is another story?


>>> I have CC'd a bunch of Intel folks who were doing some other
>>> work on cpu hotplug.  They were dealing with a race when multiple
>>> CPUs were added at once. 
>>> So I think there must be some confusion.  Perhaps xl and xend have
>>> different ideas about what the xenstore syntax is for these
>>> operations ? 
>>> Jinsong Liu et al: would you care to comment ?  Particularly about
>>> this:
>>>> A xenstore vcpu hotplug command is of the following form:
>>>> path: /local/domain/DOMID/cpu/VCPU_NUMBER/availability
>>>> values: "online" or "offline"
>> Yes, I think there must be some confusion.
>> Currently 'xm vcpu-set' command works fine with both PV and HVM vcpu
>> hotplug. 
>> Stabellini/Jackson, would your please tell me what xl recently
>> happened for vcpu hotplug? is there any different ideas xl and xend
>> about xenstore syntax? (Each time 'xm vcpu-set' executed, xend will
>> write all xenstore cpu node status) 
>>> That doesn't seem to match up with what's in xend, which seems to
>>> write "cpu_avail" in the vm tree.
>>> Thanks,
>>> Ian.

Xen-devel mailing list