From patchwork Wed Nov 14 20:50:18 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Williamson X-Patchwork-Id: 997865 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=nongnu.org (client-ip=2001:4830:134:3::11; helo=lists.gnu.org; envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 42wGqk4CB9z9s3x for ; Thu, 15 Nov 2018 07:51:12 +1100 (AEDT) Received: from localhost ([::1]:34163 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN27w-00049K-Nv for incoming@patchwork.ozlabs.org; Wed, 14 Nov 2018 15:51:08 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33551) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gN27O-000479-03 for qemu-devel@nongnu.org; Wed, 14 Nov 2018 15:50:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gN27J-0004RA-8d for qemu-devel@nongnu.org; Wed, 14 Nov 2018 15:50:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45090) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gN27J-0004Qd-2a for qemu-devel@nongnu.org; Wed, 14 Nov 2018 15:50:29 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8A591307DAB1; Wed, 14 Nov 2018 20:50:27 +0000 (UTC) Received: from gimli.home (ovpn-116-133.phx2.redhat.com [10.3.116.133]) by smtp.corp.redhat.com (Postfix) with ESMTP id DF0BF5D6A9; Wed, 14 Nov 2018 20:50:18 +0000 (UTC) From: Alex Williamson To: qemu-devel@nongnu.org Date: Wed, 14 Nov 2018 13:50:18 -0700 Message-ID: <154222737752.9288.484557356059052047.stgit@gimli.home> User-Agent: StGit/0.18-136-gffd7-dirty MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Wed, 14 Nov 2018 20:50:27 +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] [RFC for-3.2 PATCH 0/7] pcie: Enhanced link speed and width support 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: geoff@hostfission.com, mst@redhat.com Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: "Qemu-devel" QEMU exposes gen1 PCI-express interconnect devices supporting only 2.5GT/s and x1 width. It might not seem obvious that a virtual bandwidth limitation can result in a real performance degradation, but it's been reported that in some configurations assigned GPUs might not scale their link speed up to the maximum supported value if the downstream port above it only advertises limited link support. As proposed[1] this series effectively implements virtual link negotiation on downstream ports and enhances the generic PCIe root port to allow user configurable speeds and widths. The "negotiation" simply mirrors the link status of the connected downstream device providing the appearance of dynamic link speed scaling to match the endpoint device. Not yet implemented from the proposal is support for globally updating defaults based on machine type, though the foundation is provided here by allowing supporting PCIESlots to implement an instance_init callback which can call into a common helper for this. I have not specifically tested migration with this, but we already consider LNKSTA to be dynamic and the other changes implemented here are static config space changes with no changes being implemented for devices using default values, ie. they should be compatible by virtue of existing config space migration support. I think I've covered the required link related registers to support PCIe 4.0, but please let me know if I've missed any. Testing and feedback appreciated, patch 6/7 provides example qemu:arg options and requirements to use with existing libvirt. Native libvirt support TBD. Thanks, Alex [1] https://lists.gnu.org/archive/html/qemu-devel/2018-10/msg03086.html Tested-by: Geoffrey McRae --- Alex Williamson (7): pcie: Create enums for link speed and width pci: Sync PCIe downstream port LNKSTA on read qapi: Define PCIe link speed and width properties pcie: Add link speed and width fields to PCIESlot pcie: Fill PCIESlot link fields to support higher speeds and widths pcie: Allow generic PCIe root port to specify link speed and width vfio/pci: Remove PCIe Link Status emulation hw/core/qdev-properties.c | 178 ++++++++++++++++++++++++++++++++++++ hw/pci-bridge/gen_pcie_root_port.c | 2 hw/pci-bridge/pcie_root_port.c | 14 +++ hw/pci/pci.c | 4 + hw/pci/pcie.c | 118 +++++++++++++++++++++++- hw/vfio/pci.c | 9 -- include/hw/pci/pci.h | 13 +++ include/hw/pci/pcie.h | 1 include/hw/pci/pcie_port.h | 4 + include/hw/pci/pcie_regs.h | 23 ++++- include/hw/qdev-properties.h | 8 ++ qapi/common.json | 42 ++++++++ 12 files changed, 404 insertions(+), 12 deletions(-)