Re: [PATCH/RFC 7/9] Virtual network guest device driver

["Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Wed, May 16, 2007 at 12:28:00PM -0500, Anthony Liguori wrote:
> Eric Van Hensbergen wrote:
> > On 5/11/07, Anthony Liguori <aliguori-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> >>
> >> There's definitely a conversation to have here.  There are going to be a
> >> lot of small devices that would benefit from a common transport
> >> mechanism.  Someone mentioned a PV entropy device on LKML.  A
> >> host=>guest filesystem is another consumer of such an interface.
> >>
> >> I'm inclined to think though that the abstraction point should be the
> >> transport and not the actual protocol.  My concern with standardizing on
> >> a protocol like 9p would be that one would lose some potential
> >> optimizations (like passing PFN's directly between guest and host).
> >>
> >
> > I think that there are two layers - having a standard, well defined,
> > simple shared memory transport between partitions (or between
> > emulators and the host system) is certainly a prerequisite.  There are
> > lots of different decisions to made here:
> 
> What do you think about a socket interface?  I'm not sure how discovery 
> would work yet, but there are a few PV socket implementations for Xen at 
> the moment.

As a userspace apps service, I'd very much like to see a common sockets 
interface for inter-VM communication that is portable across virt systems 
like Xen & KVM. I'd see it as similar to UNIX domain sockets in style. So 
basically any app which could do UNIX domain sockets, could be ported to 
inter-VM sockets by just changing PF_UNIX to say,  PF_VIRT
Lots of interesting details around impl & security (what VMs are allowed
to talk to each other, whether this policy should be controlled by the
host, or allow VMs to decide for themselves).

> >  a) does it communicate with userspace, kernelspace, or both?
> 
> sockets are usable for both userspace/kernespace.

For userspace, it would be very easy to adapt existing sockets based
apps using IP or UNIX sockets to use inter-VM sockets, which is a big
positive.

> >  d) can all of these parameters be something controllable from userspace?
> >  e) I'm sure there are many others that I can't be bothered to think
> > of on a Friday
> 
> The biggest point of contention would probably be what goes in the 
> sockaddr structure.

Keeping it very simple would be some arbitrary 'path', similar to UNIX 
domain sockets in the abstract namespace ?

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/