> 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
