> From: Jorgen S. Hansen [mailto:jhansen@xxxxxxxxxx] > 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 agree that this is the desired behavior for a guest. > > > > It's a little tricker on the host side (doesn't matter for Hyper-V and > > probably also doesn't for VMware) because the host-side driver is a > > software device with no hardware backing it. In KVM we assume the > > vhost_vsock.ko kernel module will be loaded sufficiently early. > > Since the vmci driver is currently tied to PF_VSOCK it hasn’t been a problem, > but on the host side the VMCI driver has no hardware backing it either, so > when we move to a more appropriate solution, this will be an issue for VMCI as > well. I’ll check our shipped products, but they most likely assume that if an > upstreamed vmci module is present, it will be loaded automatically. Hyper-V Sockets is a standard feature of VMBus v4.0, so we can easily know we can and should load iff vmbus_proto_version >= VERSION_WIN10. > > Things get trickier with nested virtualization because the VM might want > > to talk to its host but also to its nested VMs. The simple way of > > fixing this would be to allow two transports loaded simultaneously and > > route traffic destined to CID 2 to the host transport and all other > > traffic to the guest transport. This sounds like a little tricky to me. 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 to the host via this feature. > This is close to the routing the VMCI driver does in a nested environment, but > that is with the assumption that there is only one type of transport. Having two > different transports would require that we delay resolving the transport type > until the socket endpoint has been bound to an address. Things get trickier if > listening sockets use VMADDR_CID_ANY - if only one transport is present, this > would allow the socket to accept connections from both guests and outer host, > but with multiple transports that won’t work, since we can’t associate a socket > with a transport until the socket is bound. > > > > > Perhaps we should discuss these cases a bit more to figure out how to > > avoid conflicts over MODULE_ALIAS_NETPROTO(PF_VSOCK). > > Agreed. Can we use the 'protocol' parameter in the socket() function: int socket(int domain, int type, int protocol) IMO currently the 'protocol' is not really used. I think we can modify __vsock_core_init() to allow multiple transport layers to be registered, and we can define different 'protocol' numbers for VMware/KVM/Hyper-V, and ask the application to explicitly specify what should be used. Considering compatibility, we can use the default transport in a given VM depending on the underlying hypervisor. -- Dexuan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
