From nobody Mon Nov 10 11:19:28 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1556119626; cv=none; d=zoho.com; s=zohoarc; b=ldatTB9N1Mzrv5FVmC/vjKdh5JP5+QHIcH7q83F47uVOjhXRBMEFUq+F+fkvjHK9Z2nz7mZwyI+/1ggC/GT+aoDZzyptL8SHOUpraA3oJo/QTf2EvdlqeyLwblotYXnjxQjFNq9AHmkuwNcU9qNQAbNJtR7WUoHwFeS/W6xSXXU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1556119626; h=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:ARC-Authentication-Results; bh=OJIvew0oFLANarEM3+m0IyXEHdIZp2iWGnDWDtcVoJY=; b=bzlXRLHyVT9gMFuKfVcdRd8uqSMqmoLz3VQkmEv3HBOgT9OIxqzFh3U9dyVguZaMELk65jtVXuoRjjZR3vl18x5gkjBOjCd0DTmHbdcq2TIlS54ymvsngeQKsXT+20NaYNJTC9Swa3amNHggF0eExSgJppIqYOqDtj5Q3ZBYzV8= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail header.from= (p=none dis=none) header.from= Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1556119626034856.4308561325532; Wed, 24 Apr 2019 08:27:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:43329 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJJnb-0006Gm-2h for importer@patchew.org; Wed, 24 Apr 2019 11:27:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJJkr-0004CI-91 for qemu-devel@nongnu.org; Wed, 24 Apr 2019 11:24:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJJkp-0004Un-Sr for qemu-devel@nongnu.org; Wed, 24 Apr 2019 11:24:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51114) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hJJkp-0004TG-ME for qemu-devel@nongnu.org; Wed, 24 Apr 2019 11:24:11 -0400 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 062173148064; Wed, 24 Apr 2019 15:24:10 +0000 (UTC) Received: from localhost (unknown [10.36.118.106]) by smtp.corp.redhat.com (Postfix) with ESMTP id 97CC55D704; Wed, 24 Apr 2019 15:24:02 +0000 (UTC) From: Stefan Hajnoczi To: Date: Wed, 24 Apr 2019 16:24:01 +0100 Message-Id: <20190424152401.28304-1-stefanha@redhat.com> 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.49]); Wed, 24 Apr 2019 15:24:10 +0000 (UTC) Content-Transfer-Encoding: quoted-printable 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] [PATCH] virtio: clarify VirtioPCIDeviceTypeInfo usage 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: sebastien.boeuf@intel.com, ehabkost@redhat.com, Stefan Hajnoczi , "Michael S. Tsirkin" Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" How to use .base_name, .generic_name, .transitional_name, and .non_transitional_name can be confusing. Existing devices have .generic_name but its behavior is somewhat magic. Devices added to new versions of the VIRTIO specification should forego transitional mode completely and always operate in non-transitional mode because there are no existing drivers for them that require backwards compatibility. This patch adds comments that hopefully make it easier for developers to decide how to fill out VirtioPCIDeviceTypeInfo. Signed-off-by: Stefan Hajnoczi --- hw/virtio/virtio-pci.h | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h index 18581854ca..debdee28b3 100644 --- a/hw/virtio/virtio-pci.h +++ b/hw/virtio/virtio-pci.h @@ -209,7 +209,9 @@ typedef struct VirtioPCIDeviceTypeInfo { * Implements both INTERFACE_PCIE_DEVICE and INTERFACE_CONVENTIONAL_PC= I_DEVICE, * but PCI Express is supported only in non-transitional mode. * - * The only type implemented by QEMU 3.1 and older. + * The only type implemented by QEMU 3.1 and older. This type is less + * explicit than the transitional and non-transitional device types. = Its + * behavior can be affected by machine type compat properties. */ const char *generic_name; /* @@ -222,6 +224,9 @@ typedef struct VirtioPCIDeviceTypeInfo { * The non-transitional device type. Optional. * * Implements INTERFACE_CONVENTIONAL_PCI_DEVICE only. + * + * New virtio device types should only define this and base_name, ther= eby + * allowing only non-transitional mode. */ const char *non_transitional_name; =20 --=20 2.20.1