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

[harry <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

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