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] [Question] vcpu-set before or after xen_pause_requested

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [Question] vcpu-set before or after xen_pause_requested
From: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
Date: Tue, 20 Apr 2010 19:08:16 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Zhai, Edwin" <edwin.zhai@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "alex.nixon@xxxxxxxxxx" <alex.nixon@xxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 20 Apr 2010 04:12:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19405.32826.995539.344701@xxxxxxxxxxxxxxxxxxxxxxxx>
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: <EB8593BCECAB3D40A8248BE0B6400A38469C6F70@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <19399.7706.36343.487108@xxxxxxxxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E026FAC6041@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <19404.31543.186398.77423@xxxxxxxxxxxxxxxxxxxxxxxx> <BC00F5384FCFC9499AF06F92E8B78A9E026FB9842F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <19405.32826.995539.344701@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acrgc1K4M+0SbGZ6Raum/z8sYJxXEgABRoTQ
Thread-topic: [Xen-devel] [Question] vcpu-set before or after xen_pause_requested
If so, things become some complicated.
I list sub-tasks to implement 'xm vcpu-set':
1. setup a reliable communication protocol between xenstore and HVM qemu/ PV 
driver, similar with what usb-add/usb-del use;
2. update old 'xm command --> xend --> xenstore' path according to new 
protocal, and keep an unify 'xm command --> xend --> xnestore' path for both 
HVM and PV;
3. update old PV driver to close-loop way;
4. update our HVM patch to close-loop way;

Is it OK, or something else ignored?


Ian Jackson wrote:
> Liu, Jinsong writes ("RE: [Xen-devel] [Question] vcpu-set before or
> after xen_pause_requested"): 
>> I think no problem here. In our test of the patch, 16 xenstore
>> changes in row (vcpu0~15), and it trigger 16 event.
> Firstly, testing is no way to eliminate the possibility of races.
> That must be done by analysis.
> Secondly, yes, you will in the current implementation get 16 watch
> triggers for 16 changes (although that's not guaranteed to remain the
> case).  But if you don't do xs_read in time for one of them you will
> miss one of the 16 different values.
>> I noticed that qemu watch xenstore nodes and handle event in a
>> close-loop way, like, usb-add/usb-del watch
>> '/local/domain/0/device-model/domid/command' node and response
>> xenstore with 'usb-added' / 'usb-deleted'.  It's one way to
>> communicate between xenstore and qemu.
> Yes, that is how it should be done.
>> However, is it the only way to communicate between qemu/xenstore, or
>> between PV/xenstore? 
>> I check 'xm vcpu-set' command path, it now works for PV domain in an
>> open-loop way: 1). PV register a xenbus_watch
>>         static struct xenbus_watch cpu_watch = {
>>                 .node = "cpu",
>>                 .callback = handle_vcpu_hotplug_event};
>>         (void)register_xenbus_watch(&cpu_watch);
>> 2). when xend write xenstore cpu node or its sub-level nodes, it
>> trigger callback function handle_vcpu_hotplug_event(), then
>> xenbus_scanf() / xenbus_read() ...  
> This is broken.  If for any reason multiple vcpu-set actions happen in
> quick succession, before the PV guest is scheduled, the
> xenbus_scanf/read will see only the last one.
> The protocol should be fixed before we implement any more of it.
> Ian.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>