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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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?

Speaking of ports, is there a registry somewhere of the well known port
numbers and/or any scheme for administering these? (a text file in the
repo would be find by me).

> > If one of the reasons for not using xenstore is the inability for
> > multiple clients to co-exist then there is no point moving to a
> > different scheme with the same (even if lesser) issue. Up until now v4v
> > has only been used by XenClient so it has avoided this issue but if we
> > take it upstream then presumably the potential for this sort of problem
> > to creep in comes back.
> > 
> > Some other things from my notes...
> > 
> > Can you remind me of the reasoning behind using VIRQ_V4V instead of
> > regular event channels? I can't see any reason why these
> > shouldn't/couldn't be regular event channels demuxed in the usual way.
> > 
> 
> No good reason, the virq can be changed to a event channel. We thought
> that event channels required other machinery to function. If we can
> deal with the event channel in the v4v driver directly I don't have any
> problem changing it to a event channel. What I have in mind is if one
> would want to use v4v in a rombios for instance where you can't rely
> on any of the xen pv driver code to be present.

I think that will be ok -- under the hood a VIRQ is just an evtchn too
so if you can make the VIRQ work you can a regular evtchn work too.

> > Are you going to submit any client code? I think the most important of
> > these would be code to make libvchan able to use v4v if it is available
> > (and both ends agree), but any other client code (like the sockets
> > interface overlay I've heard about) would be interesting to see too.
> > 
> 
> Yes. I still have to submit the kernel driver code and the v4v library that
> talks to it. But now that you've pointed out that we might be able to use
> an event channel instead of a virq, I think we might event be able to have
> a driver in userspace only.

That would be a nice property to have!

> > The patches need plenty of documentation adding to them, both in the
> > interface docs in xen/include/public (marked up such that it comes out
> > nicely in docs/html aka
> > http://xenbits.xen.org/docs/unstable/hypercall/index.html) as well as
> > design docs and any other useful material you have under docs itself.
> > 
> 
> I agree such change need a lot of document. Once we agreed on the interfaces
> I will start working on a complete documentation for them. 

Thanks!

Ian.


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