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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] watches not working from domU userspace
From: "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>
Date: Mon, 2 Jan 2006 03:24:19 -0800
Cc: Xen-devel@xxxxxxxxxxxxxxxxxxx, Ewan Mellor <ewan@xxxxxxxxxxxxx>
Delivery-date: Mon, 02 Jan 2006 11:29:19 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcYN8epKw7abc1XyRUShfdLrNjLXNwBmju9Q
Thread-topic: [Xen-devel] watches not working from domU userspace
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.


Xen-devel mailing list