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

["Cihula, Joseph" <joseph.cihula@xxxxxxxxx>]

On Saturday, December 31, 2005 1:53 AM,  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).
> 
>   -- Keir

It seems like this would add a lot of overhead.  Xenstore commands are
typically only a couple hundred bytes and since they are synchronous
(per client and excluding watches), this would leave a lot of the page
unused.  Moreover, for transient clients, such as xenstore-{read, write,
rm}, the extra setup/teardown would also add to the cost.

Joe

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