From nobody Sun Feb 8 21:12:31 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 207.211.31.81 as permitted sender) client-ip=207.211.31.81; 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 207.211.31.81 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=1595510543; cv=none; d=zohomail.com; s=zohoarc; b=T0BA448GNAeBSrGxKH4AEkwMFRNJfXdsgAdQ49Vp4ZYrLRmGoxZ5zETMtZ2az8o0WkmjD62T7m4iVyxWG/3j+wMXRZdXHjL+yCmVgCDk1C45jFQylHc6xfnyx2IDjw46AlwLE6XNopndo2BX7N26xBJXMl2EefRLSgQ18KMn0ps= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1595510543; 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=ZmMdQh28Vx10vQeKUdfn1jmSumgu9VVdUs2Bk84IOgs=; b=l24Q/AbB8Ng0c2mjGpRrEpu0/ETeoZ5GWiQRxMCxVYLBynQWi0Qb6yD0+edF16mi1yLZGH0TcA/NocVVLGb/LFHUuKqZx23Jwzu3pnbMl9GloKpGz0whctMSlDPviqwQIXPWU41oN8X/pWxr3nnPpKNlPvABDnMyGcmnT1BGia8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 207.211.31.81 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 [207.211.31.81]) by mx.zohomail.com with SMTPS id 1595510543002339.1649951288649; Thu, 23 Jul 2020 06:22:23 -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-385-H_E5iQa8P26bQKHNKNtmJw-1; Thu, 23 Jul 2020 09:22:19 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C57398005B0; Thu, 23 Jul 2020 13:22:13 +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 A698669328; Thu, 23 Jul 2020 13:22:13 +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 76849A3582; Thu, 23 Jul 2020 13:22:13 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 06NDMBc7028520 for ; Thu, 23 Jul 2020 09:22:11 -0400 Received: by smtp.corp.redhat.com (Postfix) id 47A5619D7D; Thu, 23 Jul 2020 13:22:11 +0000 (UTC) Received: from speedmetal.redhat.com (unknown [10.40.208.37]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9B5512DE99 for ; Thu, 23 Jul 2020 13:22:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595510541; 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=ZmMdQh28Vx10vQeKUdfn1jmSumgu9VVdUs2Bk84IOgs=; b=AZaRM73rFc4a1sC8HcpgZ/lz8ZJumD6oIqsq4Kzs861mcLHT6i20QwsE8FsKB7YT0D25DM QZlP2mDr5kpnF+pS4YywH1nlcu9jx+l1yllz6eSTaifquC7JPL+iWU6VFacHFNsYzDRORj XMn/CaOXRw8Bp7BKl5RGy+Ip8qhUufg= X-MC-Unique: H_E5iQa8P26bQKHNKNtmJw-1 From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH 10/32] docs: formatdomain-devices: Split out virtio information Date: Thu, 23 Jul 2020 15:21:15 +0200 Message-Id: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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.16 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" Start splitting out part of into smaller sections. Signed-off-by: Peter Krempa --- docs/formatdomain-devices-virtio.rst | 59 +++++++++++++++++++++++++++ docs/formatdomain-devices.rst | 61 +--------------------------- docs/meson.build | 1 + 3 files changed, 61 insertions(+), 60 deletions(-) create mode 100644 docs/formatdomain-devices-virtio.rst diff --git a/docs/formatdomain-devices-virtio.rst b/docs/formatdomain-devic= es-virtio.rst new file mode 100644 index 0000000000..21a0603984 --- /dev/null +++ b/docs/formatdomain-devices-virtio.rst @@ -0,0 +1,59 @@ +:anchor:`` + +Virtio-related options +~~~~~~~~~~~~~~~~~~~~~~ + +QEMU's virtio devices have some attributes related to the virtio transport= under +the ``driver`` element: The ``iommu`` attribute enables the use of emulated +IOMMU by the device. The attribute ``ats`` controls the Address Translation +Service support for PCIe devices. This is needed to make use of IOTLB supp= ort +(see `IOMMU device <#elementsIommu>`__). Possible values are ``on`` or ``o= ff``. +:since:`Since 3.5.0` + +The attribute ``packed`` controls if QEMU should try to use packed virtque= ues. +Compared to regular split queues, packed queues consist of only a single +descriptor ring replacing available and used ring, index and descriptor bu= ffer. +This can result in better cache utilization and performance. If packed +virtqueues are actually used depends on the feature negotiation between QE= MU, +vhost backends and guest drivers. Possible values are ``on`` or ``off``. +:since:`Since 6.3.0 (QEMU and KVM only)` + +:anchor:`` + +Virtio transitional devices +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:since:`Since 5.2.0` , some of QEMU's virtio devices, when used with PCI/P= CIe +machine types, accept the following ``model`` values: + +``virtio-transitional`` + This device can work both with virtio 0.9 and virtio 1.0 guest drivers,= so + it's the best choice when compatibility with older guest operating syst= ems is + desired. libvirt will plug the device into a conventional PCI slot. +``virtio-non-transitional`` + This device can only work with virtio 1.0 guest drivers, and it's the + recommended option unless compatibility with older guest operating syst= ems is + necessary. libvirt will plug the device into either a PCI Express slot = or a + conventional PCI slot based on the machine type, resulting in a more + optimized PCI topology. +``virtio`` + This device will work like a ``virtio-non-transitional`` device when pl= ugged + into a PCI Express slot, and like a ``virtio-transitional`` device othe= rwise; + libvirt will pick one or the other based on the machine type. This is t= he + best choice when compatibility with libvirt versions older than 5.2.0 is + necessary, but it's otherwise not recommended to use it. + +While the information outlined above applies to most virtio devices, there= are a +few exceptions: + +- for SCSI controllers, ``virtio-scsi`` must be used instead of ``virtio`= ` for + backwards compatibility reasons; +- some devices, such as GPUs and input devices (keyboard, tablet and mous= e), + are only defined in the virtio 1.0 spec and as such don't have a transi= tional + variant: the only accepted model is ``virtio``, which will result in a + non-transitional device. + +For more details see the `qemu patch +posting `__ +and the `virtio-1.0 +spec `__. diff --git a/docs/formatdomain-devices.rst b/docs/formatdomain-devices.rst index c789495e5d..16be7883b6 100644 --- a/docs/formatdomain-devices.rst +++ b/docs/formatdomain-devices.rst @@ -42,66 +42,7 @@ following characters: ``[a-zA-Z0-9_-]``. :since:`Since 3= .9.0` .. include:: formatdomain-devices-disk.rst .. include:: formatdomain-devices-filesystem.rst .. include:: formatdomain-devices-address.rst - -:anchor:`` - -Virtio-related options -~~~~~~~~~~~~~~~~~~~~~~ - -QEMU's virtio devices have some attributes related to the virtio transport= under -the ``driver`` element: The ``iommu`` attribute enables the use of emulated -IOMMU by the device. The attribute ``ats`` controls the Address Translation -Service support for PCIe devices. This is needed to make use of IOTLB supp= ort -(see `IOMMU device <#elementsIommu>`__). Possible values are ``on`` or ``o= ff``. -:since:`Since 3.5.0` - -The attribute ``packed`` controls if QEMU should try to use packed virtque= ues. -Compared to regular split queues, packed queues consist of only a single -descriptor ring replacing available and used ring, index and descriptor bu= ffer. -This can result in better cache utilization and performance. If packed -virtqueues are actually used depends on the feature negotiation between QE= MU, -vhost backends and guest drivers. Possible values are ``on`` or ``off``. -:since:`Since 6.3.0 (QEMU and KVM only)` - -:anchor:`` - -Virtio transitional devices -~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -:since:`Since 5.2.0` , some of QEMU's virtio devices, when used with PCI/P= CIe -machine types, accept the following ``model`` values: - -``virtio-transitional`` - This device can work both with virtio 0.9 and virtio 1.0 guest drivers,= so - it's the best choice when compatibility with older guest operating syst= ems is - desired. libvirt will plug the device into a conventional PCI slot. -``virtio-non-transitional`` - This device can only work with virtio 1.0 guest drivers, and it's the - recommended option unless compatibility with older guest operating syst= ems is - necessary. libvirt will plug the device into either a PCI Express slot = or a - conventional PCI slot based on the machine type, resulting in a more - optimized PCI topology. -``virtio`` - This device will work like a ``virtio-non-transitional`` device when pl= ugged - into a PCI Express slot, and like a ``virtio-transitional`` device othe= rwise; - libvirt will pick one or the other based on the machine type. This is t= he - best choice when compatibility with libvirt versions older than 5.2.0 is - necessary, but it's otherwise not recommended to use it. - -While the information outlined above applies to most virtio devices, there= are a -few exceptions: - -- for SCSI controllers, ``virtio-scsi`` must be used instead of ``virtio`= ` for - backwards compatibility reasons; -- some devices, such as GPUs and input devices (keyboard, tablet and mous= e), - are only defined in the virtio 1.0 spec and as such don't have a transi= tional - variant: the only accepted model is ``virtio``, which will result in a - non-transitional device. - -For more details see the `qemu patch -posting `__ -and the `virtio-1.0 -spec `__. +.. include:: formatdomain-devices-virtio.rst :anchor:`` diff --git a/docs/meson.build b/docs/meson.build index e30f213739..f7c8f12579 100644 --- a/docs/meson.build +++ b/docs/meson.build @@ -127,6 +127,7 @@ docs_rst_files =3D [ 'formatdomain-devices-disk.rst', 'formatdomain-devices-filesystem.rst', 'formatdomain-devices-address.rst', + 'formatdomain-devices-virtio.rst', ] }, { 'name': 'hacking' }, --=20 2.26.2