WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] What guarantees are provided by xenbus/xenstore?

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] What guarantees are provided by xenbus/xenstore?
From: harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 03 Oct 2005 14:14:37 +0100
Delivery-date: Mon, 03 Oct 2005 13:12:05 +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
I'm trying to work out how to correctly set up and tear down a shared
memory connection between a FE and a BE domain using xenstore.

I've looked at the blkback/blkfront code but it doesn't seem to cover
all the scenarios required for the FE and BE to be loadable modules so
I'm trying to work out what is necessary from first principles.

Having looked at the code, I'm assuming that I can rely on the following
guarantees from xenstore:

1) Transactions can be used to perform a set of writes atomically.
2) Gathers can be used to perform a set of reads atomically.
3) A watch is guaranteed to fire after a change is made.

These three guarantees are sufficient to construct a communication
channel between a FE and BE domain but the resulting solution is
somewhat complicated...

The three guarantees above result in a communication channel where:

1) Messages can be represented by transactions and gathers.
2) Messages can be reordered: by the time a watch fires, multiple
transactions may have completed and relative ordering is lost.
3) Messages can be redelivered: when a watch fires, data from previous
transactions is still present in the store.
4) Messages sharing the same field names can overwrite one another:
transactions writing the same keys will overwrite previous values even
if a watch hasn't yet completed on them.
5) Messages are not dropped unless overwritten as in 4.
6) Stale messages persist in the system indefinitely.
7) There is no explicit indication whether the other side is live.

A solution can be constructed using the following features:

1) Use a unique for all time epoch number (e.g. large, randomly
generated) to filter out stale messages.
2) Use sequence numbers within an epoch to preserve message ordering and
guarantee exactly once delivery.
3) Use a unique namespace for the field names for every possible
concurrent message (to avoid 4 above).
4) Use a heartbeat to detect whether the other side is live.

Using these features it is possible to construct a reliable, in-order
channel with exactly-once delivery which can detect channel up and down
events.

On top of this channel, it would then be relatively easy to send
messages to pass the shared page info:

1) Wait for the channel to go up.

2) When you want to connect, send a connect message with the shared page
info.

3) When you want to disconnect, send a disconnect message and wait for a
disconnected message before releasing shared resources.

4) Stop using other side's resources before replying with a disconnected
message.

5) If the channel goes down, assume the other side is dead and has
stopped using your resources.

So, this kind of solution would allow me to have loadable and unloadable
FE and BE modules and correctly establish and tear down the shared
memory comms channel when the modules are loaded and unloaded.

But, I don't think it's how anyone is intending for xenstore to be used.

So, I'm wondering what other guarantees are provided which would allow
me to construct a simpler solution.

Anyone got any hints?


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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] What guarantees are provided by xenbus/xenstore?, harry <=