On 30 May 2019, at 13:19, Stefano Garzarella <sgarz...@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
