From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [RFC][PATCH 0/5] Add V4V to Xen Date: Mon, 2 Jul 2012 15:14:20 +0100 Message-ID: <1341238460.4625.103.camel@zakaz.uk.xensource.com> References: <20120614153556.GI90181@ocelot.phlegethon.org> <20120625090537.GC1488@ocelot.phlegethon.org> <1340721486.3832.145.camel@zakaz.uk.xensource.com> <20120628103858.GB7935@spongy> <1340883253.10942.38.camel@zakaz.uk.xensource.com> <20120628114314.GB15863@spongy> <1340884734.10942.39.camel@zakaz.uk.xensource.com> <20120628121056.GC15863@spongy> <1340887016.10942.42.camel@zakaz.uk.xensource.com> <20120628134308.GD15863@spongy> <1340891262.10942.51.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jean Guyader Cc: "Tim (Xen.org)" , "Jean Guyader (3P)" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Thu, 2012-06-28 at 17:35 +0100, Jean Guyader wrote: > On 28 June 2012 14:47, Ian Campbell wrote: > > On Thu, 2012-06-28 at 14:43 +0100, Jean Guyader wrote: > >> On 28/06 01:36, Ian Campbell wrote: > >> > On Thu, 2012-06-28 at 13:10 +0100, Jean Guyader wrote: > >> > > On 28/06 12:58, Ian Campbell wrote: > >> > > > On Thu, 2012-06-28 at 12:43 +0100, Jean Guyader wrote: > >> > > > > On 28/06 12:34, Ian Campbell wrote: > >> > > > > > On Thu, 2012-06-28 at 11:38 +0100, Jean Guyader wrote: > >> > > > > > > On 26/06 03:38, Ian Campbell wrote: > >> > > > > > > > Hi, > >> > > > > > > > > >> > > > > > > > Sorry it's taken me so long to get round to responding to this. > >> > > > > > > > > >> > > > > > > > On Mon, 2012-06-25 at 10:05 +0100, Tim Deegan wrote: > >> > > > > > > > > At 22:14 +0100 on 14 Jun (1339712061), Jean Guyader wrote: > >> > > > > > > > > > On 14 June 2012 16:35, Tim Deegan wrote: > >> > > > > > > > > > > At 16:10 +0100 on 14 Jun (1339690244), Jean Guyader wrote: > >> > > > > > > > > > >> On 14/06 03:56, Tim Deegan wrote: > >> > > > > > > > > > >> > At 11:55 +0100 on 14 Jun (1339674908), Jean Guyader wrote: > >> > > > > > > > > > >> > > Are you talking about having different version of V4V driver running > >> > > > > > > > > > >> > > in the same VM? > >> > > > > > > > > > >> > > >> > > > > > > > > > >> > Yes. > >> > > > > > > > > > >> > > >> > > > > > > > > > >> > > I don't think that is a problem they both interact with Xen via > >> > > > > > > > > > >> > > hypercall directly so if they follow the v4v hypercall interface it's > >> > > > > > > > > > >> > > all fine. > >> > > > > > > > > > >> > > >> > > > > > > > > > >> > AFAICS if they both try to register the same port then one of them will > >> > > > > > > > > > >> > silently get its ring discarded. And if they both try to communicate > >> > > > > > > > > > >> > with the same remote port their entries on the pending lists will get > >> > > > > > > > > > >> > merged (which is probably not too bad). I think the possibility for > >> > > > > > > > > > >> > confusion depends on how you use the service. Still, it seems better > >> > > > > > > > > > >> > than the xenstore case, anyway. :) > >> > > > > > > > > > >> > > >> > > > > > > > > > >> > >> > > > > > > > > > >> Not silently, register_ring will return an error. > >> > > > > > > > > > > > >> > > > > > > > > > > Will it? It looks to me like v4v_ring_add just clobbers the old MFN > >> > > > > > > > > > > list. > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > Ha yes. It does that now but I think it should return an error > >> > > > > > > > > > informing up the stack that a ring has already been registered. > >> > > > > > > > > > >> > > > > > > > > Actually, I think it's deliberate, to allow a guest to re-register all > >> > > > > > > > > its rings after a suspend/resume or migration, without having to worry > >> > > > > > > > > about whether it was actually migrated into a new domain or not. > >> > > > > > > > > >> > > > > > > > Which takes us back to the original issue Tim asked about with > >> > > > > > > > cohabitation of multiple (perhaps just plain buggy or even malicious) > >> > > > > > > > v4v clients in a single domain, doesn't it? > >> > > > > > > > > >> > > > > > > > >> > > > > > > There is nothing wrong the two v4v driver running in the same guest. > >> > > > > > > The probably that Tim reported was about trying to create two connections > >> > > > > > > on the same port. Today with the code that I've submited in the RFC > >> > > > > > > one will overwrite the other silently which isn't a good thing, that can > >> > > > > > > easily be changed to notify which one got registered up the stack. > >> > > > > > > >> > > > > > So they'd somehow need to randomise (and retry) their use of source > >> > > > > > ports in order to co-exist? > >> > > > > > > >> > > > > > >> > > > > That can be assimilated to two userspace programs trying to bind to the > >> > > > > same TCP port. I think it's not v4v's responsability to solve this problem. > >> > > > > >> > > > An application using TCP doesn't need to worry about choosing its own > >> > > > source port though. > >> > > > > >> > > > Or does this only effect destination / listening ports? > >> > > > > >> > > > >> > > The guest v4v driver knows which port are in used so if you put port 0 > >> > > we will pick a random unused number for the source port. > >> > > >> > Except when there are two such drivers each doesn't know which the other > >> > one is using. > >> > > >> > >> Then the kernel will try to register the ring and the hypercall will fail > >> because it's already registered. > > > > At which point what happens? How do two unrelated V4V drivers co-exist > > given this? > > > > It happens when both driver will start registering their rings and if they are > using the same port. One will get a success out of the hypercall the other one > a failure. If we are in the case that user space used 0 for port we > will retry with > another random port number until it succeed. So the upshot is that for two v4v clients to co-exist then they must both be prepared to do this retry loop as well as to handle unexpected failures to bind to particular ports which they might have thought were free. If a particular client is buggy in this regard then the only impact is it to itself and not other, correct, clients (which is scant consolation if it is the one built into your OS and driving your network). So, not exactly ideal but I suppose it is somewhat better than XenStore (which currently has only one client which must provide a suitable API to any other XS users). Ian.