Re: [Xen-devel] watches not working from domU userspace

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

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.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel