Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Dave, > >> Instead, what I remember doing was deferring to the feedback these > >> folks received, stating that ideas that the virtio people had > >> mentioned should be considered instead. > >> > >> http://marc.info/?l=linux-netdev=135301515818462=2 > > > > I believe Andy replied to Anthony's AF_VMCHANNEL post and the > > differences between the proposed solutions. > > I'd much rather see a hypervisor neutral solution than a hypervisor > specific one which this certainly is. We've addressed this with the latest patch series, which I sent earlier today. vSockets now has support for pluggable transports, of which VMCI happens to be the first; all transport code is separated out into its own module. So the core is now hypervisor neutral. Given that, would you be willing to re-consider it, please? If at all possible, we'd like to make the current merge window. Thanks so much! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Dave, Instead, what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. http://marc.info/?l=linux-netdevm=135301515818462w=2 I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences between the proposed solutions. I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. We've addressed this with the latest patch series, which I sent earlier today. vSockets now has support for pluggable transports, of which VMCI happens to be the first; all transport code is separated out into its own module. So the core is now hypervisor neutral. Given that, would you be willing to re-consider it, please? If at all possible, we'd like to make the current merge window. Thanks so much! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
> > > Our position is that VSOCK feature set is more complete and that > > > it > > > should be possible to use transports other than VMCI for VSOCK > > > traffic, should interested parties implement them, > > > > Implementing other transports requires restructing vsock (and vmci) > > first as the current vsock code is not a hypervisor neutral > > service. > > I'm going to bite the bullet and spend the next couple of days doing > just that: factoring out the VMCI bits and hiding them behind a > transport layer. It'll be a bit rough, but it'll be a start. We'll > submit another patch series next week with that. I'm hoping that'll > get us over this hump, since it should by hypervisor agnostic at > that point. It'll be up to you guys to add virtio, though :) I sent out a patch series this morning that splits out our code into a core part, containing the socket family/operations, and a VMCI-specific part. The core makes callbacks via a new transport layer into VMCI. It's not perfect -- there's still some cruft in the core socket structure -- but it lays the foundation of a hypervisor-neutral channel, and hopefully we can build on this with your help. It'd be great if you could take a look. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, Implementing other transports requires restructing vsock (and vmci) first as the current vsock code is not a hypervisor neutral service. I'm going to bite the bullet and spend the next couple of days doing just that: factoring out the VMCI bits and hiding them behind a transport layer. It'll be a bit rough, but it'll be a start. We'll submit another patch series next week with that. I'm hoping that'll get us over this hump, since it should by hypervisor agnostic at that point. It'll be up to you guys to add virtio, though :) I sent out a patch series this morning that splits out our code into a core part, containing the socket family/operations, and a VMCI-specific part. The core makes callbacks via a new transport layer into VMCI. It's not perfect -- there's still some cruft in the core socket structure -- but it lays the foundation of a hypervisor-neutral channel, and hopefully we can build on this with your help. It'd be great if you could take a look. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
> > Our position is that VSOCK feature set is more complete and that it > > should be possible to use transports other than VMCI for VSOCK > > traffic, should interested parties implement them, > > Implementing other transports requires restructing vsock (and vmci) > first as the current vsock code is not a hypervisor neutral service. I'm going to bite the bullet and spend the next couple of days doing just that: factoring out the VMCI bits and hiding them behind a transport layer. It'll be a bit rough, but it'll be a start. We'll submit another patch series next week with that. I'm hoping that'll get us over this hump, since it should by hypervisor agnostic at that point. It'll be up to you guys to add virtio, though :) And in the meantime, are there any other glaring errors that we need to address? Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On 01/09/13 03:22, Dmitry Torokhov wrote: > On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote: >> I'd much rather see a hypervisor neutral solution than a hypervisor >> specific one which this certainly is. > > Objectively speaking neither solution is hypervisor neutral as there are > hypervisors that implement either VMCI or virtio or something else > entirely. Indeed. vmchannel is tied to virtio like vsock is tied to vmci. > Our position is that VSOCK feature set is more complete and that it > should be possible to use transports other than VMCI for VSOCK traffic, > should interested parties implement them, Implementing other transports requires restructing vsock (and vmci) first as the current vsock code is not a hypervisor neutral service. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On 01/09/13 03:22, Dmitry Torokhov wrote: On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote: I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. Objectively speaking neither solution is hypervisor neutral as there are hypervisors that implement either VMCI or virtio or something else entirely. Indeed. vmchannel is tied to virtio like vsock is tied to vmci. Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, Implementing other transports requires restructing vsock (and vmci) first as the current vsock code is not a hypervisor neutral service. cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, Implementing other transports requires restructing vsock (and vmci) first as the current vsock code is not a hypervisor neutral service. I'm going to bite the bullet and spend the next couple of days doing just that: factoring out the VMCI bits and hiding them behind a transport layer. It'll be a bit rough, but it'll be a start. We'll submit another patch series next week with that. I'm hoping that'll get us over this hump, since it should by hypervisor agnostic at that point. It'll be up to you guys to add virtio, though :) And in the meantime, are there any other glaring errors that we need to address? Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote: > From: Dmitry Torokhov > Date: Tue, 08 Jan 2013 17:41:44 -0800 > > > On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote: > >> From: Greg KH > >> Date: Tue, 8 Jan 2013 16:21:10 -0800 > >> > >> > On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: > >> >> * * * > >> >> > >> >> This series of VSOCK linux upstreaming patches include latest udpate > >> >> from > >> >> VMware to address Greg's and all other's code review comments. > >> > > >> > Dave, you acked these patches a while ago, > >> > >> Really? I'd like to see where I did that. > >> > >> Instead, what I remember doing was deferring to the feedback these > >> folks received, stating that ideas that the virtio people had > >> mentioned should be considered instead. > >> > >> http://marc.info/?l=linux-netdev=135301515818462=2 > > > > I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences > > between the proposed solutions. > > I'd much rather see a hypervisor neutral solution than a hypervisor > specific one which this certainly is. Objectively speaking neither solution is hypervisor neutral as there are hypervisors that implement either VMCI or virtio or something else entirely. Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, and on this basis we ask to include VSOCK. Thanks, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
From: Dmitry Torokhov Date: Tue, 08 Jan 2013 17:41:44 -0800 > On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote: >> From: Greg KH >> Date: Tue, 8 Jan 2013 16:21:10 -0800 >> >> > On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: >> >> * * * >> >> >> >> This series of VSOCK linux upstreaming patches include latest udpate from >> >> VMware to address Greg's and all other's code review comments. >> > >> > Dave, you acked these patches a while ago, >> >> Really? I'd like to see where I did that. >> >> Instead, what I remember doing was deferring to the feedback these >> folks received, stating that ideas that the virtio people had >> mentioned should be considered instead. >> >> http://marc.info/?l=linux-netdev=135301515818462=2 > > I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences > between the proposed solutions. I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote: > From: Greg KH > Date: Tue, 8 Jan 2013 16:21:10 -0800 > > > On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: > >> * * * > >> > >> This series of VSOCK linux upstreaming patches include latest udpate from > >> VMware to address Greg's and all other's code review comments. > > > > Dave, you acked these patches a while ago, > > Really? I'd like to see where I did that. > > Instead, what I remember doing was deferring to the feedback these > folks received, stating that ideas that the virtio people had > mentioned should be considered instead. > > http://marc.info/?l=linux-netdev=135301515818462=2 I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences between the proposed solutions. > > So definitely NACK this code and any infrastructure you've > merged which essentialy depends upon it. No, there is no infrastructure that depends on VSOCK, as VSOCK is built on top of VMCI, not the other way around. Thanks, Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote: From: Greg KH gre...@linuxfoundation.org Date: Tue, 8 Jan 2013 16:21:10 -0800 On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: * * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Dave, you acked these patches a while ago, Really? I'd like to see where I did that. Instead, what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. http://marc.info/?l=linux-netdevm=135301515818462w=2 I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences between the proposed solutions. So definitely NACK this code and any infrastructure you've merged which essentialy depends upon it. No, there is no infrastructure that depends on VSOCK, as VSOCK is built on top of VMCI, not the other way around. Thanks, Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
From: Dmitry Torokhov d...@vmware.com Date: Tue, 08 Jan 2013 17:41:44 -0800 On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote: From: Greg KH gre...@linuxfoundation.org Date: Tue, 8 Jan 2013 16:21:10 -0800 On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: * * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Dave, you acked these patches a while ago, Really? I'd like to see where I did that. Instead, what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. http://marc.info/?l=linux-netdevm=135301515818462w=2 I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences between the proposed solutions. I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On Tue, Jan 08, 2013 at 05:46:01PM -0800, David Miller wrote: From: Dmitry Torokhov d...@vmware.com Date: Tue, 08 Jan 2013 17:41:44 -0800 On Tuesday, January 08, 2013 05:30:56 PM David Miller wrote: From: Greg KH gre...@linuxfoundation.org Date: Tue, 8 Jan 2013 16:21:10 -0800 On Tue, Jan 08, 2013 at 03:59:08PM -0800, George Zhang wrote: * * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Dave, you acked these patches a while ago, Really? I'd like to see where I did that. Instead, what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. http://marc.info/?l=linux-netdevm=135301515818462w=2 I believe Andy replied to Anthony's AF_VMCHANNEL post and the differences between the proposed solutions. I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is. Objectively speaking neither solution is hypervisor neutral as there are hypervisors that implement either VMCI or virtio or something else entirely. Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, and on this basis we ask to include VSOCK. Thanks, Dmitry -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On Thu, 2012-11-15 at 15:32 -0600, Anthony Liguori wrote: > > 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... Ack. Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
On Thu, 2012-11-15 at 15:32 -0600, Anthony Liguori wrote: 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... Ack. Ben. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Sasha, Thanks for taking a look. > So all the documentation I see in the VMCI Socket Programming Guide > is about userspace programming, and the documentation in af_vsock.c > is all around implementation considerations. Agreed, we're sorely lacking in proper documentation for the internal protocol. We're in the process of writing such a specification and will post it to LKML next week at the latest. > example, whats the deal with REQUEST/REQUEST2? it appears like > something to deal with legacy code, but I'd really like to have it > documented somewhere instead of trying to figure how everything Correct, we have a legacy protocol and a v2, the latter now being the default. This particular packet is sent by the client when initiating a STREAM connection. The sequence is REQUEST(2)-> NEGOTIATE(2)->OFFER->ACCEPT. It will be properly documented in the specification we post next week. Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Sasha, Thanks for taking a look. So all the documentation I see in the VMCI Socket Programming Guide is about userspace programming, and the documentation in af_vsock.c is all around implementation considerations. Agreed, we're sorely lacking in proper documentation for the internal protocol. We're in the process of writing such a specification and will post it to LKML next week at the latest. example, whats the deal with REQUEST/REQUEST2? it appears like something to deal with legacy code, but I'd really like to have it documented somewhere instead of trying to figure how everything Correct, we have a legacy protocol and a v2, the latter now being the default. This particular packet is sent by the client when initiating a STREAM connection. The sequence is REQUEST(2)- NEGOTIATE(2)-OFFER-ACCEPT. It will be properly documented in the specification we post next week. Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Gerd, >> 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? That's correct, VMCI is wired into vSockets and we don't currently provide any way to insert another transport. > 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. Sorry, that was a bad explanation on my part. You're absolutely correct as to how it _should_ work. But it's up to Red Hat or others to get the ball rolling and motivate the necessary work on vSockets to make this happen. As Greg says, "everyone is lazy and just wants their code accepted" ;) Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
Hi Gerd, 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? That's correct, VMCI is wired into vSockets and we don't currently provide any way to insert another transport. 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. Sorry, that was a bad explanation on my part. You're absolutely correct as to how it _should_ work. But it's up to Red Hat or others to get the ball rolling and motivate the necessary work on vSockets to make this happen. As Greg says, everyone is lazy and just wants their code accepted ;) Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
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. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
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. cheers, Gerd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
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). Thanks! - Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
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). Thanks! - Andy -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
