[9fans] extending xen to allow driver development in Plan 9

["ron minnich" <rminnich@gmail.com>]

This is mostly for Richard Miller but I don't have his email. But if
you are interested in Xen, read along.

We have an ok xen environment going. Why are we doing this? Per a
certain person at xyz.com, we are looking at giving people a usable
xen-based plan 9 environment, and at the same time letting them do
driver work from Plan 9 by "poking holes" in Xen to let Plan 9 at the
real hardware. Xen supports this, we think, although we have not got
it going yet ...

I already like the situation thus far, as Plan 9 under Xen is a ton
faster than Plan 9 under qemu. You have to see it to believe it; if
anything, the Xen advantage is better than it used to be. I was
surprised.

to get to the point of poking holes in Xen, it turned out I need
pcifront. For pcifront I need xenbus. for xenbus I need xenstore.

There is xenstore support in Plan 9 already, but ...

The xenstore sez: "incomplete". What would it take to complete it?
conservative use of locks in the short term as a hack for really doing
it right in the long term? The comment is this:

 * XXX This is incomplete - needs multiplexing of request/response protocol
 * and locking between driver and kernel-only xenstore_read/write interface.

Should we set up queues for request/response? The locking seems simple
enough, is there something I'm missing?

ron