Received: by 10.192.165.148 with SMTP id m20csp5155852imm; Tue, 24 Apr 2018 14:53:39 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+6bcJWB9/oVqWVmGH5rCJMXt4zuJ4ZK8uyXGlwQgYHbk1gNGOoHFu4nj9av4fbrv5/u8kK X-Received: by 10.101.77.67 with SMTP id j3mr21993264pgt.210.1524606819768; Tue, 24 Apr 2018 14:53:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524606819; cv=none; d=google.com; s=arc-20160816; b=Qjs4ZJnPaRsRRrQ6T4Xa0hQTJNdyPdd6ZRqKCnbT68HlSfG9BvvkZqgKi8/Eyfqfak y9YxPN7WQIA/9TVCAkqiHYM25TTzPRXoLO7kWHDueTHm9eoFICrdfkv+ueMC5WcsxbVv Tic4lihjr7jP+1L2skSFaLIWupP3SR4L0kM+hx9mVCBY7VYk1YaTsSagb9vQNfLFi9lC DfRH19pcZvmQFcRd84nhf+E8AZteaxhryQMXMlgxnDXOhiu1V7P7T5nHE/hey6M/ktmZ nUpz84D0cEmw7D4NWJZ6Ja7GfePtECKej7xnIjL47lKcDCyWSSxH0vEfsPwLSK4Z3Kw8 x5OA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dmarc-filter:arc-authentication-results; bh=tt3r5jMrAyO7iLJbrUSHT1UNfuS02VvAHyo+8gJrefM=; b=nL7YLrq1qoWrJsGnvqik9WDHY6Eqiyoie/OpXpBa1UmuSfNm/op0M7EQCfORMwkLoC od50+NlhNKn/F0R6njqDiHbIZD9hzWyO9+gAxQu2Ip/SymH66+sk/P1xokYF33J4olOE kcxwLDJa8gRjRAmO/VYDQ1VH/wKFumjND5D6gW7uXiOoamBmStB8niC8deGyQZwrBfG5 RmJ/Jr3ieAnP18UbL2HvmRKxy2WYWHAL/5VrdVqYYUvRcCL3j4J0DA8ZqgAkwiAWRpr8 Uf99SB0jcrj0axktq235ma4D5vvPj2ndXCJj2+VfJA4T24ZPuto+u0Bx5IfOgHgiw8eW S6iA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h62si10393332pgc.548.2018.04.24.14.53.21; Tue, 24 Apr 2018 14:53:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751242AbeDXVv4 (ORCPT + 99 others); Tue, 24 Apr 2018 17:51:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:48232 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbeDXVvy (ORCPT ); Tue, 24 Apr 2018 17:51:54 -0400 Received: from localhost (unknown [69.71.5.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9D988205F4; Tue, 24 Apr 2018 21:51:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D988205F4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=helgaas@kernel.org Date: Tue, 24 Apr 2018 16:51:50 -0500 From: Bjorn Helgaas To: Alexander Duyck Cc: Alexander Duyck , Bjorn Helgaas , linux-pci@vger.kernel.org, virtio-dev@lists.oasis-open.org, kvm@vger.kernel.org, Netdev , "Daly, Dan" , LKML , linux-nvme@lists.infradead.org, Keith Busch , netanel@amazon.com, Don Dutile , Maximilian Heyne , "Wang, Liang-min" , "Rustad, Mark D" , David Woodhouse , Christoph Hellwig , dwmw@amazon.co.uk Subject: Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV Message-ID: <20180424215150.GB72698@bhelgaas-glaptop.roam.corp.google.com> References: <20180420162633.46077.49012.stgit@ahduyck-green-test.jf.intel.com> <20180421203437.GW28657@bhelgaas-glaptop.roam.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 21, 2018 at 05:22:27PM -0700, Alexander Duyck wrote: > On Sat, Apr 21, 2018 at 1:34 PM, Bjorn Helgaas wrote: > > For example, I'm not sure what you mean by "devices where the PF is > > not capable of managing VF resources." > > > > It *sounds* like you're saying the hardware works differently on some > > devices, but I don't think that's what you mean. I think you're > > saying something about which drivers are used for the PF and the VF. > > That is sort of what I am saying. > > So for example with ixgbe there is functionality which is controlled > in the MMIO space of the PF that affects the functionality of the VFs > that are generated on the device. The PF has to rearrange the > resources such as queues and interrupts on the device before it can > enable SR-IOV, and it could alter those later to limit what the VF is > capable of doing. > > The model I am dealing with via this patch set has a PF that is not > much different than the VFs other than the fact that it has some > extended configuration space bits in place for SR-IOV, ARI, ACS, and > whatever other bits are needed in order to support spawning isolated > VFs. OK, thanks for the explanation, I think I understand what's going on now, correct me if I'm mistaken. I added a hint about "PF" for Randy, too. These are on pci/virtualization for v4.18. commit 8effc395c209 Author: Alexander Duyck Date: Sat Apr 21 15:23:09 2018 -0500 PCI/IOV: Add pci_sriov_configure_simple() SR-IOV (Single Root I/O Virtualization) is an optional PCIe capability (see PCIe r4.0, sec 9). A PCIe Function with the SR-IOV capability is referred to as a PF (Physical Function). If SR-IOV is enabled on the PF, several VFs (Virtual Functions) may be created. The VFs can be individually assigned to virtual machines, which allows them to share a single hardware device while being isolated from each other. Some SR-IOV devices have resources such as queues and interrupts that must be set up in the PF before enabling the VFs, so they require a PF driver to do that. Other SR-IOV devices don't require any PF setup before enabling VFs. Add a pci_sriov_configure_simple() interface so PF drivers for such devices can use it without repeating the VF-enabling code. Tested-by: Mark Rustad Signed-off-by: Alexander Duyck [bhelgaas: changelog, comment] Signed-off-by: Bjorn Helgaas Reviewed-by: Greg Rose Reviewed-by: Christoph Hellwig :wq commit a8ccf8a66663 Author: Alexander Duyck Date: Tue Apr 24 16:47:16 2018 -0500 PCI/IOV: Add pci-pf-stub driver for PFs that only enable VFs Some SR-IOV PF devices provide no functionality other than acting as a means of enabling VFs. For these devices, we want to enable the VFs and assign them to guest virtual machines, but there's no need to have a driver for the PF itself. Add a new pci-pf-stub driver to claim those PF devices and provide the generic VF enable functionality. An administrator can use the sysfs "sriov_numvfs" file to enable VFs, then assign them to guests. For now I only have one example ID provided by Amazon in terms of devices that require this functionality. The general idea is that in the future we will see other devices added as vendors come up with devices where the PF is more or less just a lightweight shim used to allocate VFs. Signed-off-by: Alexander Duyck [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas Reviewed-by: Greg Rose Reviewed-by: Christoph Hellwig commit 115ddc491922 Author: Alexander Duyck Date: Tue Apr 24 16:47:22 2018 -0500 net: ena: Use pci_sriov_configure_simple() to enable VFs Instead of implementing our own version of a SR-IOV configuration stub in the ena driver, use the existing pci_sriov_configure_simple() function. Signed-off-by: Alexander Duyck Signed-off-by: Bjorn Helgaas Reviewed-by: Greg Rose Reviewed-by: Christoph Hellwig commit 74d986abc20b Author: Alexander Duyck Date: Tue Apr 24 16:47:27 2018 -0500 nvme-pci: Use pci_sriov_configure_simple() to enable VFs Instead of implementing our own version of a SR-IOV configuration stub in the nvme driver, use the existing pci_sriov_configure_simple() function. Signed-off-by: Alexander Duyck Signed-off-by: Bjorn Helgaas Reviewed-by: Christoph Hellwig