On Sun, 2005-09-25 at 12:33 +0100, Keir Fraser wrote:

We already have the mechanism: xenbus_lock. I don't think we want to go for parallelism within the kernel for xenstore comms: it'd be a fair amount of pain for something which isn't exactly speed critical. Like Andrew said, I can't transactions getting significantly longer.

We already have a permissions model based on domid (although not actually enforced due to a bug: we can fix this with one line but will require xend fixups I imagine). Space quotas will have to be by ID, too, not by the connection(s) which created them: in the case of migration, the store will be recreated by the tools, but should still be counted against the ID which owns them. So even if we multiplexed all the connections together for one domain they would still have to be separate.

Bandwidth quotas are and interesting idea: I was thinking of a dumb fairness scheme. We almost do this: we rotate the list of connections, but there's a FIXME about the unfair way we service domain pages. Or we could just measure the time we spend servicing each connection, and put the slowest ones at the tail... (socket connections would be immune, since we trust dom0 tools). I haven't thought too hard about it.

Thanks, I'll update the TODO file... Rusty.