Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen

[Tim Deegan <tim@xxxxxxx>]

At 12:40 +0100 on 07 Jun (1339072831), Tim Deegan wrote:
> Hi, 
> 
> Thanks for this.
> 
> Overall, it looks like Xen is doing a few things here:
>  - nameservice for registering services and finding endpoints;
>  - ring manipulation arithmetic;
>  - copying data; and
>  - notifying endpoints. 
> 
> The shared-ring logic was able to do all of these, with a few drawbacks:
>  - The xenstore handshake stuff is really grotty;
>  - grant maps can cause zombie domains; and
>  - it doesn't do many-to-one multicast.

We've just had a discussion of this in person, and from my notes the two
things that stand out are:

 - yes, you want to do many-to-one multiplexing, in particular to 
   avoid the server needing a ring for every client; and
 - one reason not to use Xenstore is that there is only one Xenstore
   page per VM and it may not be possible to safely share it with other
   users (in particular between a BIOS/EFI user and the main OS).

The Xenstore point is understandable, and probably something that ought
to be fixed anyway -- we have seen people run into similar problems with
BIOS drivers for blkfront and netfront.

Using one ring for all clients raises the question of access control and
admission control -- in particular how do you avoid DoS from
badly-behaved clients?

And, given your concerns about sharing an OS with an uncooperative
Xenstore client, how do you handle sharing the OS with a badly behaved
v4v client?

If we _do_ need one ring with multiple writers, and therefore Xen needs
to arbitrate writes, there's still room for the policy-based parts
(controlling connection setup, for example) to live outside the
hypervisor, openvswitch-style.

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel