From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: Inter-domain Communication using Virtual Sockets (high-level design) Date: Thu, 20 Jun 2013 12:30:29 +0100 Message-ID: <20130620113029.GC44917@ocelot.phlegethon.org> References: <51B76754.7040800@citrix.com> <20130613162705.GB55095@ocelot.phlegethon.org> <51BF555E.1040306@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <51BF555E.1040306@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ross Philipson Cc: Vincent Hanquez , David Vrabel , Xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.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.