Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

> On Aug 31, 2017, at 1:54 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: > > On Tue, Aug 29, 2017 at 03:37:07PM +0000, Jorgen S. Hansen wrote: >>> On Aug 29, 2017, at 4:36 AM, Dexuan Cui <de...@microsoft.com> wrote: >> If we allow multiple host side

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

> On Aug 29, 2017, at 4:36 AM, Dexuan Cui wrote: > >> From: Dexuan Cui >> Sent: Tuesday, August 22, 2017 21:21 >>> ... >>> ... >>> The only problem here would be the potential for a guest and a host app >> to >>> have a conflict wrt port numbers, even though they would be

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

> On Aug 22, 2017, at 11:54 AM, Stefan Hajnoczi wrote: > > On Fri, Aug 18, 2017 at 11:07:37PM +, Dexuan Cui wrote: >>> Not all features need to be supported. For example, VMCI supports >>> SOCK_DGRAM while Hyper-V and virtio do not. But features that are >>> available

Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default

> On Aug 17, 2017, at 3:55 PM, Stefan Hajnoczi wrote: > > On Thu, Aug 17, 2017 at 08:00:29AM +, Dexuan Cui wrote: >> >> Without the patch, vmw_vsock_vmci_transport.ko can automatically load >> when an application creates an AF_VSOCK socket. >> >> This is the expected

Re: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

> On Aug 16, 2017, at 12:15 AM, Dexuan Cui wrote: > > > With the current code, when vsock_dequeue_accept() is removing a sock > from the list, nothing prevents vsock_enqueue_accept() from adding a new > sock into the list concurrently. We should add a lock to protect the

Re: [PATCH net-next 1/3] VMCI: only load on VMware hypervisor

> On Aug 16, 2017, at 12:13 AM, Dexuan Cui wrote: > > > Without the patch, vmw_vsock_vmci_transport.ko and vmw_vmci.ko can > automatically load when an application creates an AF_VSOCK socket. > > This is the expected good behavior on VMware hypervisor, but as we > are