> From: Jorgen S. Hansen [mailto:jhan...@vmware.com]
> Sent: Wednesday, September 6, 2017 7:11 AM
>> ...
> > I'm currently working on NFS over AF_VSOCK and sock_diag support (for
> > ss(8) and netstat-like tools).
> >
> > Multi-transport support is lower priority for me at the moment. I'm
> > happ
> On Aug 31, 2017, at 1:54 PM, Stefan Hajnoczi wrote:
>
> On Tue, Aug 29, 2017 at 03:37:07PM +, 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 be able to coexist regardless
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Thursday, August 31, 2017 4:55 AM
> ...
> On Tue, Aug 29, 2017 at 03:37:07PM +, 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
On Tue, Aug 29, 2017 at 03:37:07PM +, 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 be able to coexist regardless of the order of initialization.
That sounds good to me.
This
> 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
> 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 fine, if restricted to their appropriate transport.
> >
> >
> From: Jorgen S. Hansen [mailto:jhan...@vmware.com]
> > On Aug 22, 2017, at 11:54 AM, Stefan Hajnoczi
> wrote:
> > ...
> > We *can* by looking at the destination CID. Please take a look at
> > drivers/misc/vmw_vmci/vmci_route.c:vmci_route() to see how VMCI
> handles
> > nested virt.
> >
> > It b
> 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 Fri, Aug 18, 2017 at 11:07:37PM +, Dexuan Cui wrote:
> > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > > CID is not really used by us, because we only support guest<->host
> > communication,
> > > and don't support guest<->guest communication. The Hyper-V host
> > references
> > > e
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > CID is not really used by us, because we only support guest<->host
> communication,
> > and don't support guest<->guest communication. The Hyper-V host
> references
> > every VM by VmID (which is invisible to the VM), and a VM can only talk t
On Fri, Aug 18, 2017 at 03:07:30AM +, Dexuan Cui wrote:
> > From: Jorgen S. Hansen [mailto:jhan...@vmware.com]
> > Sent: Thursday, August 17, 2017 08:17
> > >
> > > Putting aside nested virtualization, I want to load the transport (vmci,
> > > Hyper-V, vsock) for which there is paravirtualized
> From: Jorgen S. Hansen [mailto:jhan...@vmware.com]
> Sent: Thursday, August 17, 2017 08:17
> >
> > Putting aside nested virtualization, I want to load the transport (vmci,
> > Hyper-V, vsock) for which there is paravirtualized hardware present
> > inside the guest.
>
> Good points. Completely ag
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, August 17, 2017 10:04
> I would avoid module parameters at all costs.
>
> It is the worst possible interface for users of your software.
>
> You really need to fundamentally solve the problems related to making
> sure the proper
From: Dexuan Cui
Date: Thu, 17 Aug 2017 08:00:29 +
> @@ -73,6 +74,10 @@ struct vmci_transport_recv_pkt_info {
> struct vmci_transport_packet pkt;
> };
>
> +static bool skip_hypervisor_check;
> +module_param(skip_hypervisor_check, bool, 0444);
> +MODULE_PARM_DESC(hot_add, "If set, att
> 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 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 VMware hypervisor, but as we
> are going to add hv_sock.ko (i.e. Hyper-
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 VMware hypervisor, but as we
are going to add hv_sock.ko (i.e. Hyper-V transport for AF_VSOCK), we
should make sure vmw_vsock_vmci_transport.
17 matches
Mail list logo
