Re: Inter-domain Communication using Virtual Sockets (high-level design)

[Tim Deegan <tim@xen.org>]

Hi,

At 14:28 -0400 on 17 Jun (1371479326), Ross Philipson wrote:
> >I'd be very interested to hear the v4v authors' opinions on this VSOCK
> >draft, btw -- in particular if it (or something similar) can provide all
> >v4v's features without new hypervisor code, I'd very much prefer it.
> 
> I guess I cannot be 100% just by reading the part of the spec on the low 
> level transport mechanism. We originally tried to use a grant based 
> model and ran into issue. Two of the most pronounced were:
> 
>  - Failure of grantees to release grants would cause hung domains under 
> certain situations. This was discussed early in the V4V RFC work that 
> Jean G. did. I am not sure if this has been fixed and if so, how. There 
> was a suggestion about a fix in a reply from Daniel a while back.

I think that using grant-copy can sort this out.  I believe that with v2
grant tables a grant can be marked as 'copy-only'.

>  - Synchronization between guests was very complicated without a 
> central arbitrator like the hypervisor.

I think that the VSOCK backend is intended to be that arbitrator, but
with the nice properties of allowing multiple arbitrators in a
partitioned system (with independent administrators) and of moving all
the arbitration code out of the hypervisor.

The down-side is that rather than allowing a generic many-to-one
multiplexed channel, VSOCK would provide such a channel _only_ for
connection requests (or at least, adding other uses might require
changing the manager).  That seems OK to me, but you might have other
use cases?

Another down-side is having to bounce requests off an intermediate VM
will add some latency, but again if it's only at connection-setup time
that seems OK.

> Also this solution may have some scaling issues. If I understand the 
> model being proposed here, each ring which I guess is a connection 
> consumes an event channel. In the large number of connections scenario 
> is this not a scaling problem?

I think it relies on the proposed changes to extend the number of event
channels; other than that I suspect it will scale better than the
current v4v 'select' model, where the client must scan every ring
looking for the one that's changed.

Cheers,

Tim.