> On Aug 31, 2017, at 1:54 PM, Stefan Hajnoczi 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 wrote:
>> If we allow multiple host side transports, virtio host side support and
>> vmci should
> 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 able to
>>> operate fin
> 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 should behave identic
> 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 good behavior on VMwar
> 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 list.
>
For the VMCI
> 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 going to add hv_sock.ko (
