[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <KL1P15301MB00088FBEB371152A913981BABF820@KL1P15301MB0008.APCP153.PROD.OUTLOOK.COM>
Date: Wed, 16 Aug 2017 22:33:43 +0000
From: Dexuan Cui <decui@...rosoft.com>
To: "Jorgen S. Hansen" <jhansen@...are.com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
KY Srinivasan <kys@...rosoft.com>,
"Haiyang Zhang" <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
George Zhang <georgezhang@...are.com>,
Michal Kubecek <mkubecek@...e.cz>, Asias He <asias@...hat.com>,
Stefan Hajnoczi <stefanha@...hat.com>,
"Vitaly Kuznetsov" <vkuznets@...hat.com>,
Cathy Avery <cavery@...hat.com>,
"jasowang@...hat.com" <jasowang@...hat.com>,
Rolf Neugebauer <rolf.neugebauer@...ker.com>,
Dave Scott <dave.scott@...ker.com>,
"Marcelo Cerri" <marcelo.cerri@...onical.com>,
"apw@...onical.com" <apw@...onical.com>,
"olaf@...fle.de" <olaf@...fle.de>,
"joe@...ches.com" <joe@...ches.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Dan Carpenter <dan.carpenter@...cle.com>
Subject: RE: [PATCH net-next 1/3] VMCI: only load on VMware hypervisor
> From: Jorgen S. Hansen [mailto:jhansen@...are.com]
> > 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
Powered by blists - more mailing lists