Re: [Xen-devel] [RFC][PATCH 0/5] Add V4V to Xen

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-06-28 at 17:35 +0100, Jean Guyader wrote:
> On 28 June 2012 14:47, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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 <tim@xxxxxxx> 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.


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