Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752860AbdI1PFg (ORCPT ); Thu, 28 Sep 2017 11:05:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52718 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750775AbdI1PFe (ORCPT ); Thu, 28 Sep 2017 11:05:34 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8CE302EC6A3 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=ddutile@redhat.com Subject: Re: [PATCH] uio/uio_pci_generic: Add SR-IOV support To: David Woodhouse , Alexander Duyck References: <1506517162.30379.2.camel@infradead.org> <20170927220005.GB23674@bhelgaas-glaptop.roam.corp.google.com> <1506550852.7476.33.camel@infradead.org> <1506606369.7476.96.camel@infradead.org> Cc: Bjorn Helgaas , Greg Kroah-Hartman , linux-pci , linux-kernel , Alexander Duyck , "Bryant G. Ly" , Bodong Wang , Alex Williamson , "Michael S. Tsirkin" , kvm@vger.kernel.org From: Don Dutile Message-ID: <7bbb6cce-3462-fbb2-9ae4-5c08ab2b01b4@redhat.com> Date: Thu, 28 Sep 2017 11:05:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1506606369.7476.96.camel@infradead.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 28 Sep 2017 15:05:34 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1575 Lines: 35 On 09/28/2017 09:46 AM, David Woodhouse wrote: > On Thu, 2017-09-28 at 08:22 -0400, Don Dutile wrote: >> >> After reading Alex's response, I now understand Dave's question >> better and why the patch won't work in general. > > UIO doesn't work "in general". It requires a very *specific* userspace > driver for the hardware in question, which needs to know what it's > doing. > >> In every SRIOV capable device I've run into to date, the PF has >> to know the VFs are being assigned due to some resource mgmt, if not >> internal (e.g., switch) configuration reasons. >> The reasons are often subtle. > > Sure. If there's actually a userspace driver (which in my case there > isn't), and if that's needed for the hardware ins question (which in my > case it isn't), then it'd need to do that before enabling the VFs via > the user-level sysfs interface of which you speak. > >> From the context of the patches (uio), why aren't VFs enabled via >> user-level sysfs interface? That was provided for user-mgmt apps >> to have a PCIe-generic/common, device-independent method of VF >> enablement > > That is *precisely* what we're doing. But the user-space sysfs > interface doesn't actually *exist* unless a driver is bound to the > device in question, with a .sriov-configure method. Which is where I > came in... :) > ah, nickel summary: no in-kernel driver w/.sriov-configure method. if so, now I'm up to speed with you.... hmmmm.... so, that would imply we need an in-kernel, pcie-common, .sriov-configure method that's invoked if a driver isn't bound to a device? ... yes?