Re: [RFC] vsock: proposal to support multiple transports at runtime

[Jorgen Hansen <jhansen@vmware.com>]

On 30 May 2019, at 13:19, Stefano Garzarella <sgarzare@redhat.com> wrote:
> 
> On Tue, May 28, 2019 at 04:01:00PM +0000, Jorgen Hansen wrote:
>>> On Thu, May 23, 2019 at 04:37:03PM +0100, Stefan Hajnoczi wrote:
>>>> On Tue, May 14, 2019 at 10:15:43AM +0200, Stefano Garzarella wrote:
> 
>>>>> 
>>>>> 
>>>>> 2. listen() / recvfrom()
>>>>> 
>>>>>    a. use the 'host side transport', if the socket is bound to
>>>>>       VMADDR_CID_HOST, or it is bound to VMADDR_CID_ANY and there is no
>>>>>       guest transport.
>>>>>       We could also define a new VMADDR_CID_LISTEN_FROM_GUEST in order to
>>>>>       address this case.
>>>>>       If we want to support multiple 'host side transport' running at the
>>>>>       same time, we should find a way to allow an application to bound a
>>>>>       specific host transport (e.g. adding new VMADDR_CID_LISTEN_FROM_KVM,
>>>>>       VMADDR_CID_LISTEN_FROM_VMWARE, VMADDR_CID_LISTEN_FROM_HYPERV)
>>>> 
>>>> Hmm...VMADDR_CID_LISTEN_FROM_KVM, VMADDR_CID_LISTEN_FROM_VMWARE,
>>>> VMADDR_CID_LISTEN_FROM_HYPERV isn't very flexible.  What if my service
>>>> should only be available to a subset of VMware VMs?
>>> 
>>> You're right, it is not very flexible.
>> 
>> When I was last looking at this, I was considering a proposal where
>> the incoming traffic would determine which transport to use for
>> CID_ANY in the case of multiple transports. For stream sockets, we
>> already have a shared port space, so if we receive a connection
>> request for < port N, CID_ANY>, that connection would use the
>> transport of the incoming request. The transport could either be a
>> host->guest transport or the guest->host transport. This is a bit
>> harder to do for datagrams since the VSOCK port is decided by the
>> transport itself today. For VMCI, a VMCI datagram handler is allocated
>> for each datagram socket, and the ID of that handler is used as the
>> port. So we would potentially have to register the same datagram port
>> with all transports.
> 
> So, do you think we should implement a shared port space also for
> datagram sockets?

Yes, having the two socket types work the same way seems cleaner to me. We should at least cover it in the design.

> For now only the VMWare implementation supports the datagram sockets,
> but in the future we could support it also on KVM and HyperV, so I think
> we should consider it in this proposal.

So for now, it sounds like we could make the VMCI transport the default transport for any host side datagram socket, then.

>> 
>> The use of network namespaces would be complimentary to this, and
>> could be used to partition VMs between hypervisors or at a finer
>> granularity. This could also be used to isolate host applications from
>> guest applications using the same ports with CID_ANY if necessary.
>> 
> 
> Another point to the netns support, I'll put it in the proposal (or it
> could go in parallel with the multi-transport support).
> 

It should be fine to put in the proposal that we rely on namespaces to provide this support, but pursue namespaces as a separate project.

Thanks,
Jorgen