[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [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? Thanks, Jinsong 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 Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |