Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming

From: Anthony Liguori
Date: Thu Nov 15 2012 - 16:32:08 EST


On 11/07/2012 12:58 AM, Gerd Hoffmann wrote:
On 11/05/12 19:19, Andy King wrote:
Hi David,

The big and only question is whether anyone can actually use any of
this stuff without your proprietary bits?

Do you mean the VMCI calls? The VMCI driver is in the process of being
upstreamed into the drivers/misc tree. Greg (cc'd on these patches) is
actively reviewing that code and we are addressing feedback.

Also, there was some interest from RedHat into using vSockets as a unified
interface, routed over a hypervisor-specific transport (virtio or
otherwise, although for now VMCI is the only one implemented).

Can you outline how this can be done? From a quick look over the code
it seems like vsock has a hard dependency on vmci, is that correct?

When making vsock a generic, reusable kernel service it should be the
other way around: vsock should provide the core implementation and an
interface where hypervisor-specific transports (vmci, virtio, xenbus,
...) can register themself.

This was already done in a hypervisor neutral way using virtio:

http://lists.openwall.net/netdev/2008/12/14/8

The concept was Nacked and that led to the abomination of virtio-serial. If an address family for virtualization is on the table, we should reconsider AF_VMCHANNEL.

I'd be thrilled to get rid of virtio-serial...

Regards,

Anthony Liguori


cheers,
Gerd

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/