[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH (V9) 0/2] Add V4V to Xen

On Fri, 2013-05-31 at 12:29 -0400, Ross Philipson wrote:
> On 05/31/2013 05:26 AM, Vincent Hanquez wrote:
> > On 05/31/2013 10:01 AM, Ian Campbell wrote:
> >> I think we need to see and agree on both the client and hypervisor side
> >> before either can be committed, since review on either could cause ABI
> >> changes.
> > Yes, of course. Once some more code is ready, but as of now, we still
> > need review and comments on
> > the hypervisor side to make sure the hypervisor part itself is ready
> > (soundness,design,security,etc).
> >
> > I want to note however that the v4v capability provided is modeled like
> > a simplified "network" stack,
> > so that the design is suppose to stand by itself without any client code.
> >
> >> What is your upgrade plan for libvchan users? Is it to add vsock support
> >> to vchan?
> > I'm not aware of such a plan, nor i'm aware of libvchan or what it
> > does/doesn't provides in the first place.
> > If that make sense, then a plan could be devised.
> >
> I am not sure where this requirement to support the libvchan interface 
> or library (?) came from.

libvchan is the existing upstream interface for guest to guest
communication. It has been part of upstream Xen for at least one if not
two releases and has existing users.

I don't really think we want to have two totally separate such
interfaces, and neither do I think it is right to simply throw away an
existing interface just because something new and supposedly more shiny
has come along.

IMHO libvchan needs to support v4v, either directly or via vsock and
fallback to its existing mechanisms if v4v isn't available.

I believe I've said this in response to various v4v postings in the


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.