From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [RFC][PATCH 0/5] Add V4V to Xen Date: Mon, 25 Jun 2012 10:05:37 +0100 Message-ID: <20120625090537.GC1488@ocelot.phlegethon.org> References: <20120607094225.GB15139@spongy.cam.xci-test.com> <20120607114031.GP70339@ocelot.phlegethon.org> <20120607153657.GX70339@ocelot.phlegethon.org> <20120613104858.GC23207@boiler.cam.xci-test.com> <20120613114427.GA21809@ocelot.phlegethon.org> <20120614145608.GG90181@ocelot.phlegethon.org> <20120614151043.GB24063@spongy> <20120614153556.GI90181@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline 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: Ian Campbell , Jean Guyader , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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 runni= ng > >> > > 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 i= t's > >> > > all fine. > >> > > >> > AFAICS if they both try to register the same port then one of them w= ill > >> > silently get its ring discarded. =A0And if they both try to communic= ate > >> > with the same remote port their entries on the pending lists will get > >> > merged (which is probably not too bad). =A0I think the possibility f= or > >> > confusion depends on how you use the service. =A0Still, it seems bet= ter > >> > than the xenstore case, anyway. :) > >> > > >> > >> Not silently, register_ring will return an error. > > > > Will it? =A0It 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. = That raises the question of how a v4v client ought to handle migration; doesn't it have to rely on other OS components to notify it that one has happened? Cheers, Tim.