9 messages in com.xensource.lists.xen-develRE: [Xen-devel] watches not working f...| From | Sent On | Attachments |
|---|---|---|
| Cihula, Joseph | 30 Dec 2005 21:38 | |
| Keir Fraser | 31 Dec 2005 01:52 | |
| Cihula, Joseph | 02 Jan 2006 03:23 | |
| Keir Fraser | 03 Jan 2006 03:24 | |
| Ewan Mellor | 03 Jan 2006 10:12 | |
| Keir Fraser | 04 Jan 2006 02:37 | |
| Cihula, Joseph | 06 Jan 2006 17:54 | |
| Keir Fraser | 07 Jan 2006 01:14 | |
| Keir Fraser | 07 Jan 2006 02:49 |
| Subject: | RE: [Xen-devel] watches not working from domU userspace |
|---|---|
| From: | Cihula, Joseph (jose...@intel.com) |
| Date: | 12/30/2005 09:38:31 PM |
| List: | com.xensource.lists.xen-devel |
On Thursday, December 22, 2005 7:34 AM, Ewan Mellor <mailto:ew...@xensource.com> wrote:
On Thu, Dec 15, 2005 at 03:33:08AM -0800, Cihula, Joseph wrote:
It seems that xenstore watches do not work from domU userspace (they obviously do for drivers).
In some preliminary debugging of this, there are two aspects of the failure: not sending the watch to xenstore and not handling watch events for userspace watches. The former can be easily fixed by adding the missing 'case XS_WATCH:' to xenbus_dev_write() in xenbus_dev.c. The latter is more difficult to fix. So before I tackle it, I wanted to see if anyone else was already working on a solution or just had some thoughts to share on possible solutions.
No-one's working on this at the moment, as far as I am aware, and you are more than welcome to attack the problem. The problem is that the interface exposed through /proc/xen/xenbus does not handle the demultiplexing of watch events when they fire. It's only simple bookkeeping that is missing: userspace processes will need to block on reading /proc/xen/xenbus, and then you need to
o keep track of every register event so that you can demux the correct watches firing and unblock the correct reader; o tear down the state that you hold internally whenever someone sends an unregister message; o if the connection to userspace is closed before the watch is unregistered, unregister it on their behalf; o deliver watches to the kernel correctly too.
The interface presented through /proc/xen/xenbus should be the same as that presented through the unix domain socket used by dom0, so you should be able to borrow lots of code from the existing xenstore library and move that into kernel space.
Cheers,
Ewan.
This is the approach that I've taken so far (I had to pause my work to finish up another project).
However, when the watch bookkeeping is combined with the transaction bookkeeping (which is already there) this is a lot of duplication with what xenstored already has to do for each connection. I'm wondering if it wouldn't be better to add a sub-connection id to xenstored and xenbus so that each xenbus client would be seen by xenstored as a separate (sub)connection. Then watches and transactions would not need any special code in xenbus, as xenstored would handle the tracking and cleanup.
This method would either need to change the xenstore wire protocol or co-opt the req_id field (which doesn't seem to be used). While some additional code would have to be added to xenstored, I think that a fair amount of code (and many synchronization locks/mutexes) in xenbus could be removed.
What do you think?
Joseph Cihula (Linux) Software Security Architect Open Source Technology Center Intel Corp.
*** These opinions are not necessarily those of my employer ***
_______________________________________________ Xen-devel mailing list Xen-...@lists.xensource.com http://lists.xensource.com/xen-devel