From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: xl/SR-IOV: disposition of VFs when PF disappears? Date: Mon, 27 Oct 2014 09:35:34 -0400 Message-ID: <20141027133534.GC4050@laptop.dumpdata.com> References: <544E4A4E020000780004267D@mail.emea.novell.com> <1414414666.23883.13.camel@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XikSc-0006X3-6V for xen-devel@lists.xenproject.org; Mon, 27 Oct 2014 13:35:50 +0000 Content-Disposition: inline In-Reply-To: <1414414666.23883.13.camel@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Ian Jackson , Wei Liu , xen-devel , Jan Beulich , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Mon, Oct 27, 2014 at 12:57:46PM +0000, Ian Campbell wrote: > On Mon, 2014-10-27 at 12:36 +0000, Jan Beulich wrote: > > All, > > > > Intel reports that the sequence > > > > - xl pci-assignable-add > > - briefly run guest using that device [not sure whether that's really a > > necessary step] > > - xl pci-assignable-add > > > > results in both VF and PF being listed as assignable (the fact that as a > > result the PF handed to a guest doesn't work is secondary here, as I > > think this is a driver issue). Is that really how it should be? Shouldn't > > instead all VFs get removed when the PF device (e.g. due to the > > PF driver getting unloaded, which is a necessary part of making it > > assignable) goes away? Or is it required for the admin to manually > > remove the assignable VFs prior to making the PF go away? I am not sure I see the problem. If the user wishes to give the PF and VF to a guest they should be able to do so? > > xl is just controlling/exposing the set of devices which are bound to > pciback here. (pci-assignable-list is literally a readdir loop over the > relevant sysfs dir). > > I'm not sure if it should be up to (lib)xl, pciback or the core Linux > pci stuff to handle the creation/destruction of VF devices when the PF > driver is unbound/assigned. In fact I'm not even sure if VF lifetime is > in any way tied to the PF driver state. It is. When we detect that the device is a VF we set some flag so that the PF won't try to de-allocate the VFs. > > I've added Konrad for a kernel-size pciback perspective. > > Ian. >