[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.