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] watches not working from domU userspace

On Sat, Dec 31, 2005 at 09:52:49AM +0000, Keir Fraser wrote:

> On 31 Dec 2005, at 05:38, Cihula, Joseph wrote:
> >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.
> How about add a new command XS_NEW_CONNECTION, taking a grant reference 
> and an event channel? This would then set up a new inter-domain event 
> channel and messaging memory page, and then commands would no longer go 
> via the kernel at all.
> One drawback is it would then be very hard for the kernel to tell 
> whether any xenstore transactions are in progress in user space. This 
> is a problem since transaction state is not copied during save/restore. 
> Either that needs to happen, or transactional xenstore code needs to 
> handle 'spurious' failures at any point in a transaction (handle EAGAIN 
> on any transactional read/write, not just on commit).

Could Xenstored not simply "save up" the EAGAIN until the commit?  If a domain
migrated in the middle of a transaction, then Xenstored would see a
transaction handle that was invalid for that connection.  In that case, it
could simply ignore all writes until a commit, in which case it would return
EAGAIN, just as if the transaction had seen a conflicting write.

I think that forcing clients to handle EAGAIN for all messages, not just
commit, would be undesirable.


Xen-devel mailing list