From nobody Mon Apr 29 08:03:40 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.120 as permitted sender) client-ip=207.211.31.120; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.120 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1592428686; cv=none; d=zohomail.com; s=zohoarc; b=musI5NFXNdusHwb3Z5VP6gNgT92rNg1Sz8ObwXdJfewoh5TAIqkSkQTRK8uCIw4y4ov5IJFu7fwvlpo0u/gZDRuvnBTRbbYvlGLxrDDwyMZQZT0eC4ukmPruU2Bc2RZlYH43oPmykQ+ZVm4ZMP3+6RXpczLy+tiNvZy1TpG+vS0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1592428686; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=GD6Lyu7diFm3FTdAkd9DopYpOSmgUQSFHM5xTNiYnZg=; b=AAv6CeU3UvFAFliUbIiqiaJVzJPPbbf7s/igqHxB90KrvhO+8LYJgvsUnGdx/4af8pQrJURmIIfsgPn7KrXmXvzwE+o1mPHon9YSEWpDGJV67trLqhYdDcm4UGe6eQqHXVelWys5PHPFLk5N62ZJ6at/SKQ9BF0rDiKcVFbbUvU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.120 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by mx.zohomail.com with SMTPS id 1592428686505926.1618064340192; Wed, 17 Jun 2020 14:18:06 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-307-AbUoUQywPCqFPLlXa6gcsg-1; Wed, 17 Jun 2020 17:18:03 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BC0591800D42; Wed, 17 Jun 2020 21:17:57 +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 EFE365D9D3; Wed, 17 Jun 2020 21:17:56 +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 8299A833C6; Wed, 17 Jun 2020 21:17:54 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 05HLHrpv004297 for ; Wed, 17 Jun 2020 17:17:53 -0400 Received: by smtp.corp.redhat.com (Postfix) id 5745160CD0; Wed, 17 Jun 2020 21:17:53 +0000 (UTC) Received: from vhost2.laine.org (ovpn-114-232.phx2.redhat.com [10.3.114.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id EE51A60C80; Wed, 17 Jun 2020 21:17:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592428685; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=GD6Lyu7diFm3FTdAkd9DopYpOSmgUQSFHM5xTNiYnZg=; b=XUPfWRM6K7gLUoioe7uHVSr+FLa0WSAus8e3L3MtPnTPsIL+QcuteA78qPEuLg+yJYBYn9 yRjhjkxaNvL17c5bkAqSYX/yhDnz+wkJJSwySfLPzYvGlfrDYohAwud6i7zMnIP1rtVIuS CZegpi6MVQaxuyAubWU3+VQCzdAPXGc= X-MC-Unique: AbUoUQywPCqFPLlXa6gcsg-1 From: Laine Stump To: libvir-list@redhat.com Subject: [PATCH] qemu: auto-assign hostdev interface devices to PCIe Date: Wed, 17 Jun 2020 17:17:45 -0400 Message-Id: <20200617211745.3704591-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Cc: Paulo de Rezende Pinatti 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: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Until recently, an would automatically be assigned model "rtl8139" (the default on x86 machinetypes), which in turn would lead to the device being assigned a PCI address on a conventional PCI controller (i.e. a pcie-to-pci-bridge). If the network was a typical Linux host bridge-based network that used an emulated device, this would be appropriate, since the guest actually would get an emulated rtl8139 NIC, and that device is a conventional PCI device. However, if the network being used was a pool of hostdev devices, the guest would get an actual PCIe network device assigned from the host via VFIO; while the interface model in that case is irrelevant for the QEMU commandline to assign the device, the PCI address would have already been assigned prior to runtime, so the address assignment would be done based on the model=3D'rtl8139' - a conventional PCI device. VFIO assignment of a PCIe device to a conventional PCI slot works, but we would rather have these devices in a PCIe slot. Since commit bdb8f2e4186, if points to a etwork that is a pool of hostdev devices, the interface model will be _unset_ by default. This patch uses that information when deciding what type of slot to assign to the device: since all hostdev network interfaces are SR-IOV VFs, and *all* SR-IOV network cards are PCIe, it is safe to assume that the VFs are PCIe and we should assign then to a PCIe slot in the guest. Signed-off-by: Laine Stump Reviewed-by: Andrea Bolognani --- (NB: all talk of PCIe vs. conventional PCI is irrelevant for machinetypes that don't support PCIe - any requirement for PCIe is "squashed" down to just "PCI" in those cases) (Note to Paulo - I realize this doesn't describe exactly what happens on s390, since the default interface model in that case is "virtio" rather than "rtl8139", and this patch should actually cause no behavior change on S390. I'm Cc'ing you since you're the author of the other patch I mention in the commit message, and also so you can try running your same tests with this patch added, and verify that it really doesn't break anything for S390.) src/qemu/qemu_domain_address.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index 07431343ed..05cf251cd5 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -734,6 +734,14 @@ qemuDomainDeviceCalculatePCIConnectFlags(virDomainDevi= ceDefPtr dev, if (net->model =3D=3D VIR_DOMAIN_NET_MODEL_E1000E) return pcieFlags; =20 + /* the only time model can be "unknown" is for type=3D'hostdev' + * or for type=3D'network' where the network is a pool of + * hostdev devices. These will always be pcie on the host, and + * should be pcie in the guest if it supports pcie. + */ + if (net->model =3D=3D VIR_DOMAIN_NET_MODEL_UNKNOWN) + return pcieFlags; + return pciFlags; } =20 --=20 2.25.4