From nobody Mon Nov 10 11:20:35 2025 Delivered-To: importer@patchew.org Received-SPF: temperror (zoho.com: Error in retrieving data from DNS) 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=temperror (zoho.com: Error in retrieving data from DNS) 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=1556197863; cv=none; d=zoho.com; s=zohoarc; b=Q9BIFvojGzyKxOR8UNZJXcuYBCIw9QNUfhbDA0sj8+kH4vpvbUyn9psLansunYVm0PTcszZc0dQ1rpq1wZrSdfffta8/INQ2rM2VppPEruTfcgcpUOAPdfs96zj/CU94y+BvJLgybaVU2zzyypU9PSYYVD7ZQOgDimIY3guCOl8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1556197863; 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=wmbzgSGKzcqWC3ufKql3o8L1dGTBbIMUUW+yn1jbYps=; b=ZTUmv1Ld2M1/hPORb3h6mr8HzWCOtH/IEtv3yKy8WK6tE2AhNphec76r3hlnvPQgPdmsBLnnR0IPV+9T5ciHu98i1onLKMfA1D3yUJ38fcaTcRZqTiG2E30RKf9TB3U/z/ZrYlbfiUTASemN4jJSILOFr/4SCbb87syQXWaXWIo= ARC-Authentication-Results: i=1; mx.zoho.com; spf=temperror (zoho.com: Error in retrieving data from DNS) 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 (209.51.188.17 [209.51.188.17]) by mx.zohomail.com with SMTPS id 1556197863693164.893508628806; Thu, 25 Apr 2019 06:11:03 -0700 (PDT) Received: from localhost ([127.0.0.1]:56918 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJe9D-0006i2-24 for importer@patchew.org; Thu, 25 Apr 2019 09:10:43 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55900) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJe8M-0006MN-JW for qemu-devel@nongnu.org; Thu, 25 Apr 2019 09:09:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJe8L-00072z-NG for qemu-devel@nongnu.org; Thu, 25 Apr 2019 09:09:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42998) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hJe8L-0006zA-He for qemu-devel@nongnu.org; Thu, 25 Apr 2019 09:09:49 -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 mx1.redhat.com (Postfix) with ESMTPS id D1D568E5AF; Thu, 25 Apr 2019 13:09:45 +0000 (UTC) Received: from localhost (ovpn-117-82.ams2.redhat.com [10.36.117.82]) by smtp.corp.redhat.com (Postfix) with ESMTP id 323055C21A; Thu, 25 Apr 2019 13:09:40 +0000 (UTC) From: Stefan Hajnoczi To: Date: Thu, 25 Apr 2019 14:09:39 +0100 Message-Id: <20190425130939.29674-1-stefanha@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 25 Apr 2019 13:09:45 +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 v2] 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 Reviewed-by: Eduardo Habkost --- v2: * Drop incorrect mention of machine type compat properties [ehabkost] --- hw/virtio/virtio-pci.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h index 18581854ca..0bd1fff942 100644 --- a/hw/virtio/virtio-pci.h +++ b/hw/virtio/virtio-pci.h @@ -209,7 +209,8 @@ 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. */ const char *generic_name; /* @@ -222,6 +223,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