> From: Dexuan Cui > Sent: Wednesday, August 16, 2017 15:34 > > From: Jorgen S. Hansen [mailto:jhansen@xxxxxxxxxx] > > > 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, > > > > Jorgen > > Thank you for explaining the background! > Then I'll make a new patch, following your suggestion. > > -- Dexuan Hi Jorgen, David, Just now I posted a new patch "[PATCH] vsock: only load vmci transport on VMware hypervisor by default" to replace this patch. @Jorgen: FWIW, with the new patch, when I create an AF_VSOCK sockets on Hyper-V, vmw_vmci.ko is also automatically loaded and 3 lines of kernel messages are printed, but I think I'm OK with this, since it's harmless. -- Dexuan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
