> On Aug 16, 2017, at 12:13 AM, Dexuan Cui <de...@microsoft.com> wrote: > > > Without the patch, vmw_vsock_vmci_transport.ko and vmw_vmci.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.ko doesn't load on Hyper-V, > otherwise there is a -EBUSY conflict when both vmw_vsock_vmci_transport.ko > and hv_sock.ko try to call vsock_core_init() on Hyper-V.
The VMCI driver (vmw_vmci.ko) is used both by the VMware guest support (VMware Tools primarily) and by our Workstation product. Always disabling the VMCI driver on Hyper-V means that user won’t be able to run Workstation nested in Linux VMs on Hyper-V. Since the VMCI driver itself isn’t the problem here, maybe we could move the check to vmw_vsock_vmci_transport.ko? Ideally, there should be some way for a user to have access to both protocols, but for now disabling the VMCI socket transport for Hyper-V (possibly with a module option to skip that check and always load it) but leaving the VMCI driver functional would be better, Thanks, Jorgen
