From nobody Thu May 15 12:22:23 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1522245996427874.393961702078; Wed, 28 Mar 2018 07:06:36 -0700 (PDT) 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 05C5EC05E753; Wed, 28 Mar 2018 14:06:35 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D15AE5D76A; Wed, 28 Mar 2018 14:06:34 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id A05124CAA6; Wed, 28 Mar 2018 14:06:34 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id w2SE6Mis028093 for ; Wed, 28 Mar 2018 10:06:22 -0400 Received: by smtp.corp.redhat.com (Postfix) id A53C1215CDC7; Wed, 28 Mar 2018 14:06:22 +0000 (UTC) Received: from inaba.usersys.redhat.com (ovpn-204-126.brq.redhat.com [10.40.204.126]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 24A53215CDC5 for ; Wed, 28 Mar 2018 14:06:21 +0000 (UTC) From: Andrea Bolognani To: libvir-list@redhat.com Date: Wed, 28 Mar 2018 16:06:07 +0200 Message-Id: <20180328140610.8414-9-abologna@redhat.com> In-Reply-To: <20180328140610.8414-1-abologna@redhat.com> References: <20180328140610.8414-1-abologna@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH 08/11] conf: Prefer pcie-to-pci-bridge to dmi-to-pci-bridge X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com 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.31]); Wed, 28 Mar 2018 14:06:35 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" Both pcie-to-pci-bridge and dmi-to-pci-bridge can be used to create a traditional PCI topology in a pure PCIe guest such as those using the x86_64/q35 or aarch64/virt machine type; however, the former should be preferred, as it doesn't need to obey limitation of real hardware and is completely architecture-agnostic. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=3D1520821 Signed-off-by: Andrea Bolognani Reviewed-by: John Ferlan --- src/conf/domain_addr.c | 59 +++++++++++++++++++++++++++++++++++++++++-----= ---- 1 file changed, 49 insertions(+), 10 deletions(-) diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c index b0709f8295..8964973e03 100644 --- a/src/conf/domain_addr.c +++ b/src/conf/domain_addr.c @@ -416,6 +416,7 @@ virDomainPCIAddressSetGrow(virDomainPCIAddressSetPtr ad= drs, size_t i; int model; bool needDMIToPCIBridge =3D false; + bool needPCIeToPCIBridge =3D false; =20 add =3D addr->bus - addrs->nbuses + 1; if (add <=3D 0) @@ -436,27 +437,41 @@ virDomainPCIAddressSetGrow(virDomainPCIAddressSetPtr = addrs, model =3D VIR_DOMAIN_CONTROLLER_MODEL_PCI_BRIDGE; =20 /* if there aren't yet any buses that will accept a - * pci-bridge, and the caller is asking for one, we'll need to - * add a dmi-to-pci-bridge first. + * pci-bridge, but we need one for the device's PCI address + * to make sense, it means the guest only has a PCIe topology + * configured so far, and we need to create a traditional PCI + * topology to accomodate the new device. */ needDMIToPCIBridge =3D true; + needPCIeToPCIBridge =3D true; for (i =3D 0; i < addrs->nbuses; i++) { if (addrs->buses[i].flags & VIR_PCI_CONNECT_TYPE_PCI_BRIDG= E) { needDMIToPCIBridge =3D false; + needPCIeToPCIBridge =3D false; break; } } - if (needDMIToPCIBridge && add =3D=3D 1) { + + /* Prefer pcie-to-pci-bridge, fall back to dmi-to-pci-bridge */ + if (addrs->isPCIeToPCIBridgeSupported) + needDMIToPCIBridge =3D false; + else + needPCIeToPCIBridge =3D false; + + if ((needDMIToPCIBridge || needPCIeToPCIBridge) && add =3D=3D = 1) { /* We need to add a single pci-bridge to provide the bus * our legacy PCI device will be plugged into; however, we * have also determined that there isn't yet any proper - * place to connect that pci-bridge we're about to add (on - * a system with pcie-root, that "proper place" would be a - * dmi-to-pci-bridge". So, to give the pci-bridge a place - * to connect, we increase the count of buses to add, - * while also incrementing the bus number in the address - * for the device (since the pci-bridge will now be at an - * index 1 higher than the caller had anticipated). + * place to connect that pci-bridge we're about to add, + * which means we're dealing with a pure PCIe guest. We + * need to create a traditional PCI topology, and for that + * we have two options: dmi-to-pci-bridge + pci-bridge or + * pcie-root-port + pcie-to-pci-bridge (the latter of which + * is pretty much a pci-bridge as far as devices attached + * to it are concerned and as such makes the pci-bridge + * unnecessary). Either way, there's going to be one more + * controller than initially expected, and the 'bus' part + * of the device's address will need to be bumped. */ add++; addr->bus++; @@ -525,6 +540,30 @@ virDomainPCIAddressSetGrow(virDomainPCIAddressSetPtr a= ddrs, } } =20 + if (needPCIeToPCIBridge) { + /* We need a pcie-root-port to plug pcie-to-pci-bridge into; howev= er, + * qemuDomainAssignPCIAddresses() will, in some cases, create a du= mmy + * PCIe device and reserve an address for it in order to leave the + * user with an empty pcie-root-port ready for hotplugging, and if + * we didn't do anything other than adding the pcie-root-port here + * it would be used for that, which we don't want. So we change the + * connect flags to make sure only the pcie-to-pci-bridge will be + * connected to the pcie-root-port we just added, and another one + * will be allocated for the dummy PCIe device later on. + */ + if (virDomainPCIAddressBusSetModel(&addrs->buses[i], + VIR_DOMAIN_CONTROLLER_MODEL_PCI= E_ROOT_PORT) < 0) { + return -1; + } + addrs->buses[i].flags =3D VIR_PCI_CONNECT_TYPE_PCIE_TO_PCI_BRIDGE; + i++; + + if (virDomainPCIAddressBusSetModel(&addrs->buses[i++], + VIR_DOMAIN_CONTROLLER_MODEL_PCI= E_TO_PCI_BRIDGE) < 0) { + return -1; + } + } + for (; i < addrs->nbuses; i++) { if (virDomainPCIAddressBusSetModel(&addrs->buses[i], model) < 0) return -1; --=20 2.14.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list