From patchwork Mon Jul 18 17:11:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Williamson X-Patchwork-Id: 9234943 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id BEA6860865 for ; Mon, 18 Jul 2016 17:26:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AD3E31FF8F for ; Mon, 18 Jul 2016 17:26:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A2120205A8; Mon, 18 Jul 2016 17:26:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 525071FF8F for ; Mon, 18 Jul 2016 17:26:39 +0000 (UTC) Received: from localhost ([::1]:49211 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPCJS-0002QO-9w for patchwork-qemu-devel@patchwork.kernel.org; Mon, 18 Jul 2016 13:26:38 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPC54-0004dL-Eh for qemu-devel@nongnu.org; Mon, 18 Jul 2016 13:11:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPC50-00084a-DG for qemu-devel@nongnu.org; Mon, 18 Jul 2016 13:11:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPC50-00084V-7c for qemu-devel@nongnu.org; Mon, 18 Jul 2016 13:11:42 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E55617F402 for ; Mon, 18 Jul 2016 17:11:41 +0000 (UTC) Received: from gimli.home (ovpn-116-224.phx2.redhat.com [10.3.116.224]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6IHBfhk021376; Mon, 18 Jul 2016 13:11:41 -0400 From: Alex Williamson To: qemu-devel@nongnu.org Date: Mon, 18 Jul 2016 11:11:41 -0600 Message-ID: <20160718171129.10820.34269.stgit@gimli.home> In-Reply-To: <20160718170853.10820.88397.stgit@gimli.home> References: <20160718170853.10820.88397.stgit@gimli.home> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 18 Jul 2016 17:11:41 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PULL 1/1] vfio/pci: Hide ARI capability X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marcel Apfelbaum Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP QEMU supports ARI on downstream ports and assigned devices may support ARI in their extended capabilities. The endpoint ARI capability specifies the next function, such that the OS doesn't need to walk each possible function, however this next function is relative to the host, not the guest. This leads to device discovery issues when we combine separate functions into virtual multi-function packages in a guest. For example, SR-IOV VFs are not enumerated by simply probing the function address space, therefore the ARI next-function field is zero. When we combine multiple VFs together as a multi-function device in the guest, the guest OS identifies ARI is enabled, relies on this next-function field, and stops looking for additional function after the first is found. Long term we should expose the ARI capability to the guest to enable configurations with more than 8 functions per slot, but this requires additional QEMU PCI infrastructure to manage the next-function field for multiple, otherwise independent devices. In the short term, hiding this capability allows equivalent functionality to what we currently have on non-express chipsets. Signed-off-by: Alex Williamson Reviewed-by: Marcel Apfelbaum --- hw/vfio/pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c index 44783c5..c8436a1 100644 --- a/hw/vfio/pci.c +++ b/hw/vfio/pci.c @@ -1828,6 +1828,7 @@ static int vfio_add_ext_cap(VFIOPCIDevice *vdev) switch (cap_id) { case PCI_EXT_CAP_ID_SRIOV: /* Read-only VF BARs confuse OVMF */ + case PCI_EXT_CAP_ID_ARI: /* XXX Needs next function virtualization */ trace_vfio_add_ext_cap_dropped(vdev->vbasedev.name, cap_id, next); break; default: