lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <882468393.42962386.1354807693049.JavaMail.root@vmware.com> Date: Thu, 6 Dec 2012 07:28:13 -0800 (PST) From: Andy King <acking@...are.com> To: Anthony Liguori <aliguori@...ibm.com> Cc: pv-drivers@...are.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, virtualization@...ts.linux-foundation.org, gregkh@...uxfoundation.org, David Miller <davem@...emloft.net>, georgezhang@...are.com, Benjamin Herrenschmidt <benh@...nel.crashing.org>, Gerd Hoffmann <kraxel@...hat.com> Subject: Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming Hi Anthony, > 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 finally had a look at your patch. Please correct me if I'm wrong, but it seems that the peer of an AF_VMCHANNEL connection is a virtio channel inside the hypervisor, i.e., the other end is _not_ sockets, right? That's quite a bit different from vSockets, where both sides use the socket interface, even within the VMX process in our hypervisor. We also intend for arbitrary host processes -- those outside the hypervisor -- to use it via the sockets interface. We have shipping applications that do just that, where communication is between a guest process and a host service, with both sides using the standard socket API but with the vSockets address family. We also encourage people to write such VM-to-host applications, and we've been shipping the vSockets header in our host-side products to allow people to do just that. So I think in that sense vSockets is somewhat more general, and we'd obviously prefer to go with our socket family and address structure if LKML is open to something like this. Thanks! - Andy PS I realize we still owe LKML a spec for the vSockets protocol. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists