From nobody Mon Feb 9 23:15:17 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 205.139.110.61 as permitted sender) client-ip=205.139.110.61; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-1.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 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=1586972064; cv=none; d=zohomail.com; s=zohoarc; b=G7XCwvYT10Z9vcwnJ1oBppbDbVZ90O2UokylCJ9lsXTWjKRNtsWATa4aMJODAZdXTMYCtFAQu/cHSMHAc7T9OV4S6VZa+ZtFxunRbJqDyz7qO2exU0S3Qim6z26eB5WUPgT/AtRSA8jeYPVJQPWaHwjcP43a9xkVxcqfCw8x7Eo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1586972064; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=lvWSLEpXpoM5eKQiEbxBcyGCxmx5Q4L/NQblCktT63w=; b=VNBih4Ts4WPG41hTYIqfDdB/zXUZBJRNm1mJqROwaIrdY9m1mAObVQPbkUlxkydI9pKsc3IZGbQSHmHkdddnQU9uNbi6rS4o6pdCVivvQLjT4Q2ajGBKdLQCv4apO/MGV8Ofcz013jG3unlzQwQH3+P2ftec891I/ZMVaqYaltE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 205.139.110.61 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-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by mx.zohomail.com with SMTPS id 15869720646530.25191437637317904; Wed, 15 Apr 2020 10:34:24 -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-372-x-zc1PK8O96d8Ytd3W_hJg-1; Wed, 15 Apr 2020 13:32:13 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ED8438010E4; Wed, 15 Apr 2020 17:32:07 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C07E51265B2; Wed, 15 Apr 2020 17:32:07 +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 6B34818089CF; Wed, 15 Apr 2020 17:32:07 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 03FHVk3P020435 for ; Wed, 15 Apr 2020 13:31:46 -0400 Received: by smtp.corp.redhat.com (Postfix) id A4D2A11D2D9; Wed, 15 Apr 2020 17:31:46 +0000 (UTC) Received: from kinshicho.usersys.redhat.com (unknown [10.40.195.84]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 90E8311A267 for ; Wed, 15 Apr 2020 17:31:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1586971935; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=lvWSLEpXpoM5eKQiEbxBcyGCxmx5Q4L/NQblCktT63w=; b=jUzD25jwJY0mB2/qJed9QBv/XkqPSt3j6Un9lgctfmEsjgpT1y7XWGmKF8kHQw8UI92yEN qaNTktKECEIDcUtwc/EdWtxMQYhGEx8ueCyhSiCO5Wm9GquBkWRFur2QOFgI6qjjMz7Kly ++6IxE1idASX9k6XGR1ORosiCeJdBxU= X-MC-Unique: x-zc1PK8O96d8Ytd3W_hJg-1 From: Andrea Bolognani To: libvir-list@redhat.com Subject: [libvirt PATCH 2/4] docs: Move sections around in pci-addresses.rst Date: Wed, 15 Apr 2020 19:31:34 +0200 Message-Id: <20200415173136.500247-3-abologna@redhat.com> In-Reply-To: <20200415173136.500247-1-abologna@redhat.com> References: <20200415173136.500247-1-abologna@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com 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.11 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" The section about VFIO devices is kept separate from the rest because it's less about domain XML and guest OS disagreeing on the PCI address of a device, and more about which of the two PCI addresses in the domain XML is even relevant to the guest OS. The section on zPCI addresses, on the other hand, falls squarely in the "more complex cases" category, so it should live in the corresponding section. Signed-off-by: Andrea Bolognani Reviewed-by: Cornelia Huck --- docs/pci-addresses.rst | 57 +++++++++++++++++++++--------------------- 1 file changed, 28 insertions(+), 29 deletions(-) diff --git a/docs/pci-addresses.rst b/docs/pci-addresses.rst index 0b83bb231f..566c81d957 100644 --- a/docs/pci-addresses.rst +++ b/docs/pci-addresses.rst @@ -158,36 +158,8 @@ Once again, while the PCI addresses seen in the domain= XML and those seen by the guest OS do not match, the relationships between the various devices are preserved. =20 - -Device assignment -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - -When using VFIO to assign host devices to a guest, an additional -caveat to keep in mind that the guest OS will base its decisions upon -the *target address* (guest side) rather than the *source address* -(host side). - -For example, the domain XML snippet - -:: - - - - -
- -
- - -will result in the device showing up as ``0000:00:01.0`` in the -guest OS rather than as ``0001:08:00.1``, which is the address of the -device on the host. - -Of course, all the rules and behaviors described above still apply. - - zPCI addresses -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +-------------- =20 For s390x machines, PCI addresses are handled yet differently. No topology information is relayed in the PCI addresses; instead, the @@ -252,3 +224,30 @@ will yield the following result in a Linux guest: :: =20 0007:00:00.0 Ethernet controller: Red Hat, Inc. Virtio network device + + +Device assignment +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +When using VFIO to assign host devices to a guest, an additional +caveat to keep in mind that the guest OS will base its decisions upon +the *target address* (guest side) rather than the *source address* +(host side). + +For example, the domain XML snippet + +:: + + + + +
+ +
+ + +will result in the device showing up as ``0000:00:01.0`` in the +guest OS rather than as ``0001:08:00.1``, which is the address of the +device on the host. + +Of course, all the rules and behaviors described above still apply. --=20 2.25.2