From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: [PATCH 1/2 V3] PCI: introduce device assignment interface and refactory related code Date: Mon, 21 Jul 2014 08:01:13 -0600 Message-ID: <1405951273.4463.4.camel@ul30vt.home> References: <1405081802-419-1-git-send-email-ethan.zhao@oracle.com> <1405084407.4098.59.camel@ul30vt.home> <1405088147.4098.64.camel@ul30vt.home> <1405907916.4463.2.camel@ul30vt.home> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" , linux-pci , "e1000-devel@lists.sourceforge.net" , "vaughan.cao@oracle.com" , "jesse.brandeburg@intel.com" , Ethan Zhao , Ethan Zhao , "linux.nics@intel.com" , "konrad.wilk@oracle.com" , "gleb@kernel.org" , "bhelgaas@google.com" , "boris.ostrovsky@oracle.com" , netdev , "bruce.w.allan@intel.com" , linux-kernel , "john.ronciak@intel.com" , "david.vrabel@citrix.com" , "pbonzini@redhat.com" To: Yuval Mintz Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: e1000-devel-bounces@lists.sourceforge.net List-Id: netdev.vger.kernel.org On Mon, 2014-07-21 at 13:17 +0000, Yuval Mintz wrote: > > >> > > > This patch introduces two new device assignment functions > > >> > > > > > >> > > > pci_iov_assign_device(), > > >> > > > pci_iov_deassign_device() > > >> > > > > > >> > > > along with the existed one > > >> > > > > > >> > > > pci_vfs_assigned() > > >> > > > > > >> > > > They construct the VFs assignment management interface, used to > > >> > > > assign/ deassign device to VM and query the VFs reference counter. > > >> > > > instead of direct manipulation of device flag. > > >> > > >> Sorry for the late intrusion into the conversation, and perhaps it's > > >> a bit unrelated, but given that you're creating a 'VF assignment management' > > >> perhaps it's the right place to add some sort of mechanism in order > > >> to prevent module removal once one of its VFs is assigned. > > >> [e.g., incrementing module reference count] > > >> > > >> At the moment [to the best of my knowledge] there's no mechanism > > >> preventing the 'not-so-bright' user from removing the driver, and no > > >> good will come out of it. > > > > > > On what module would the reference count be increased, the PF? The > > > entire "VF assigned" interface is a hack to work around poor > > > architectures like legacy KVM device assignment where there's no > > > proper device owner for the VF. This is "fixed" by using VFIO instead > > > and hopefully deprecating legacy KVM assignment. Thanks, > > > > To explain what Alex said, in another word, if VMs access VF via VFIO driver, > > the owner of the device is VFIO, in this case, if you unload PF driver, you still > > need to unload VFIO first, then unload PF driver. but the PF driver knows how to > > notify the VFIO driver to unload. > > But without VFIO like driver, for example some of current code will assign > > devcie (PF/VF) directly to KVM or XEN without driver in the middle. and the PF > > driver doesn't know how to unbind the assignment... > > Hi, > > I thought about perhaps incrementing the reference count of the PF's module > [i.e., the module supplying the driver for the PF] directly, so THAT module won't > be removable as long as the VF is assigned. > > Although I don't know whether the module is even accessible; Can you derive a > pointer to a module from a net_device struct? A VF is not necessarily a net device. A pci_dev does have a physfn pointer though. ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired