On Fri, May 31, 2019 at 09:24:49AM +0000, Jorgen Hansen wrote: > 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. >
Okay, I'll add this point on a v2 of this proposal! > > 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. > Yes, make sense. > >> > >> 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. Sure. I'll send a v2 adding all the points discussed to be sure that we are aligned. Then I'll start working on it if we agree on the proposal. Thanks, Stefano
