Re: [Xen-devel] Inter-domain Communication using Virtual Sockets (high-level design)

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

> -----Original Message-----
> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Thursday, June 20, 2013 7:30 AM
> To: Ross Philipson
> Cc: David Vrabel; Xen-devel@xxxxxxxxxxxxx; Vincent Hanquez
> Subject: Re: [Xen-devel] Inter-domain Communication using Virtual
> Sockets (high-level design)
> 
> 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.

I agree that it scales better as things stand now. We are exploring
solution to remove this limitation and provide a guest with info on
what has changed. 

> 
> Cheers,
> 
> Tim.

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