From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793563804; b=TOO9DW3REBJValCL2KKDuDzTGPMITySJvP50II9ijOANsxWLZLZd2ptiqdvboQ8uRi6Q zhDeGXvY5MiT74SX0R9btj7DZLOrKCkwcTvHuq7YTeh22Qp4bNeLmswy56u27bdW4j0Nk h54AYSIq/QP/ertOfd5/WfY/Mc6kHCIqJpKbVxnSoKsL3tZ6uOQ4jME+HQZtjIVF0zYkZ Q6FMG/0K1AndzB8sXuqO+qxndGfAmpN92iUjCI+k74SjGpApnzbXTe4HNZLiBXB400IZ1 s0/93h6Ojfna9FWYKFk3sGtX64IAr0vDdZxO3w7yGb4PSrnLSTU4Fxv2MTk8FMJs4Zg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793563804; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:Received:Received:Resent-To: Resent-From:Resent-Date:Resent-Message-ID:From:To:Cc:Subject: In-Reply-To:References:Date:Message-ID:User-Agent:MIME-Version: Content-Type:Content-Transfer-Encoding:Lines:X-Scanned-By; bh=gck7WLOTrBQhNTX4CI2N2ElJBfdRYTOJB0Zo1uYJWh4=; b=DiAhM47G6My5MblDSxHF25dmfpN8663/0tbX4IKBA+LytfUUl+gyM4EN38Y86e35Z9dT 4p6IuwyThGTpBOfR19DLXvuPFsv/JbqP5JhU7NC3nhxce6r1vI02asSohLe4TuE1Id9N4 AbpPkXx6voJGnBVo7ua4D8ucWXXnLrNzcpm1BYnuTESSgqrbTcjTb9p12k5FvFhKXAVwE LtBwc+qGejmdNKoBIDj80fVY8ns0bFvnZg/AByPAuUOtKaqOKKwjvtmZdr5cyV94o/UUc aDRtzRrulP2q7KgLmTJKzfgaU9dqV0UutKtjqtWSCggrjjXQmkN00MGPHwKat5Aj6Fw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fImlEoN2; arc=none smtp.remote-ip=170.10.133.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5BB7B606A324 for ; Sun, 1 Nov 2026 20:10:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 5BB7B606A324 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fImlEoN2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1793563802; h=from:from: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:resent-to: resent-from:resent-message-id:in-reply-to:in-reply-to: references:references; bh=gck7WLOTrBQhNTX4CI2N2ElJBfdRYTOJB0Zo1uYJWh4=; b=fImlEoN2TWMYjc/Xe99MiwvMjzOspS5snbaaEts0Qznce41AJYLsqhCb0pxoXRpR77vTgV gXfriEC3Tl05HPslEVDqsIOuoGF634+XonZkTOtDgiAjFoJ2UBfZoAscoIMatiH6f17YMu eBjXeEr46es+2/43wwJOMxdiTa0XRzA= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-612-urAbHKg2Pm61HrOGJHCLTg-1; Sun, 01 Nov 2026 15:10:00 -0500 X-MC-Unique: urAbHKg2Pm61HrOGJHCLTg-1 X-Mimecast-MFC-AGG-ID: urAbHKg2Pm61HrOGJHCLTg_1793563796 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5AA941954AE2; Sun, 1 Nov 2026 20:09:55 +0000 (UTC) Received: from blackfin.pond.sub.org (unknown [10.44.22.2]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9BC5C30002CB; Sun, 1 Nov 2026 20:09:52 +0000 (UTC) Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id 46A7D21E6A04; Sun, 01 Nov 2026 21:09:50 +0100 (CET) Resent-To: 17746591750@163.com, alistair@alistair23.me, graf@amazon.com, FangSheng.Huang@amd.com, michael.roth@amd.com, jamin_lin@aspeedtech.com, kane_chen@aspeedtech.com, palmer@dabbelt.com, rbolshakov@ddn.com, foss@defmacro.it, sebastian.huber@embedded-brains.de, fam@euphon.net, jiaxun.yang@flygoat.com, lizhijian@fujitsu.com, atar4qemu@gmail.com, edgar.iglesias@gmail.com, jasowangio@gmail.com, liwei1518@gmail.com, npiggin@gmail.com, zhangckid@gmail.com, titusr@google.com, wuhaotsh@google.com, arei.gonglei@huawei.com, berto@igalia.com, mark.cave-ayland@ilande.co.uk, junjie.cao@intel.com, pasic@linux.ibm.com, zhao1.liu@intel.com, rathc@linux.ibm.com, its@irrelevant.dk, stefanb@linux.vnet.ibm.com, clg@kaod.org, xen-devel@lists.xenproject.org, conor@kernel.org, luc@lmichel.fr, david@kernel.org, lixianglai@loongson.cn, maobibo@loongson.cn, pbarbuda@microsoft.com, yoshinori.sato@nifty.com, qemu-arm@nongnu.org, qemu-block@nongnu.org, qemu-devel@nongnu.org, qemu-ppc@nongnu.org, qemu-riscv@nongnu.org, qemu-s390x@nongnu.org, john.levon@nutanix.com, thanos.makatos@nutanix.com, kfting@nuvoton.com, den@openvz.org, elena.ufimtseva@oracle.com, jag.raman@oracle.com, daniel.barboza@oss.qualcomm.com, philmd@oss.qualcomm.com, pierrick.bouvier@oss.qualcomm.com, phil@philjordan.eu, tangtao1634@phytium.com.cn, chao.liu@processmission.com, jiri@resnulli.us, sam@rfc1149.net, anisa.su@samsung.com, alex@shazbot.org, farosas@suse.de, mohamed@unpredictable.fr, kvm@vger.kernel.org, linux-cxl@vger.kernel.org, alistair.francis@wdc.com, anthony@xenproject.org, jic23@kernel.org, kbusch@kernel.org, mchehab+huawei@kernel.org, sstabellini@kernel.org, peter.maydell@linaro.org, richard.henderson@linaro.org, zhiwei_liu@linux.alibaba.com, zhenwei.pi@linux.dev, adityag@linux.ibm.com, alifm@linux.ibm.com, amachhiw@linux.ibm.com, borntraeger@linux.ibm.com, brueckner@linux.ibm.com, farman@linux.ibm.com, harshpb@linux.ibm.com, iii@linux.ibm.com, jjherne@linux.ibm.com, milesg@linux.ibm.com, mjrosato@linux.ibm.com Resent-From: Markus Armbruster Resent-Date: Sun, 01 Nov 2026 21:09:50 +0100 Resent-Message-ID: <87qzh41fg1.fsf@pond.sub.org> From: Markus Armbruster To: Daniel P. =?utf-8?Q?Berrang=C3=A9?= Cc: Markus Armbruster , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , qemu-devel@nongnu.org, Michael Roth , John Snow , Peter Maydell , Mauro Carvalho Chehab , Pierrick Bouvier , Paolo Bonzini , Kostiantyn Kostiuk , Eric Blake , David Hildenbrand , Igor Mammedov , "Edgar E. Iglesias" , Jason Wang , Marcelo Tosatti , kvm@vger.kernel.org, Alberto Garcia , Kevin Wolf , Hanna Reitz , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , Zhao Liu , Jonathan Cameron , Junjie Cao , Anisa Su , Elena Ufimtseva , Jagannathan Raman , John Levon , Thanos Makatos , =?utf-8?Q?C=C3=A9dric?= Le Goater , Cornelia Huck , Eric Farman , Matthew Rosato , Richard Henderson , Ilya Leoshkevich , qemu-block@nongnu.org, linux-cxl@vger.kernel.org, qemu-s390x@nongnu.org, "Michael S. Tsirkin" , Sergio Lopez , qemu-arm@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Daniel Henrique Barboza , Liu Zhiwei , Chao Liu , qemu-riscv@nongnu.org, Song Gao <17746591750@163.com>, Bibo Mao , Xianglai Li , Jiaxun Yang , Pedro Barbuda , Mohamed Mediouni , Nicholas Piggin , Harsh Prateek Bora , Amit Machhiwal , qemu-ppc@nongnu.org, Zhang Chen , Li Zhijian , Alistair Francis , Alexander Graf , "Gonglei (Arei)" , zhenwei pi , Ani Sinha , Luc Michel , =?utf-8?Q?C=C3=A9dric?= Le Goater , Jamin Lin , Kane Chen , Samuel Tardieu , "Denis V. Lunev" , FangSheng Huang , Tyrone Ting , Hao Wu , Keith Busch , Klaus Jensen , Jesper Devantier , Aditya Gupta , Glenn Miles , Conor Dooley , Sebastian Huber , Halil Pasic , Christian Borntraeger , Jason Herne , Titus Rwantare , Stefano Stabellini , Anthony PERARD , Peter Xu , Chinmay Rath , Hendrik Brueckner , xen-devel@lists.xenproject.org, Roman Bolshakov , Phil Dennis-Jordan , Fam Zheng , Farhan Ali , Alex Williamson , Tao Tang , Stefan Berger , Fabiano Rosas , Mark Cave-Ayland , Artyom Tarasenko , Yoshinori Sato , Jiri Pirko , Eric Auger , Laurent Vivier Subject: Re: [PATCH v7 54/65] qdev: adjust PciDevfn declared type In-Reply-To: ("Daniel P. =?utf-8?Q?Berrang?= =?utf-8?Q?=C3=A9=22's?= message of "Thu, 29 Oct 2026 15:11:41 +0000") References: <20261020-qom-qapi-v7-0-431a86b02b58@redhat.com> <20261020-qom-qapi-v7-54-431a86b02b58@redhat.com> <87zevz5h4k.fsf@pond.sub.org> <87o6ce47rr.fsf@pond.sub.org> Date: Fri, 30 Oct 2026 10:21:05 +0100 Message-ID: <87o6cba6im.fsf@pond.sub.org> User-Agent: Gnus/5.13 (Gnus v5.13) X-Mailing-List: kvm@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Daniel P. Berrang=C3=A9 writes: > On Wed, Oct 28, 2026 at 08:13:44AM +0100, Markus Armbruster wrote: >> Daniel P. Berrang=C3=A9 writes: >>=20 >> > On Tue, Oct 27, 2026 at 03:54:03PM +0100, Markus Armbruster wrote: >> >> Marc-Andr=C3=A9 Lureau writes: >> >>=20 >> >> > Hi >> >> > >> >> > On Fri, Oct 23, 2026 at 2:04=E2=80=AFPM Daniel P. Berrang=C3=A9 wrote: >> >> >> >> >> >> On Tue, Oct 20, 2026 at 02:46:11PM +0400, Marc-Andr=C3=A9 Lureau w= rote: >> >> >> > PciDevfn is a bit special, since it accepts integer and string as >> >> >> > setter, but only output integer as getter. >> > >> > snip >> > >> >> > But I agree we >> >> > could do better. >> >> > >> >> > There are multiple options. We could keep declaring the property as >> >> > str instead. In this case, the getter should probably return a stri= ng >> >> > for consistency and correctness. This might surprise some existing >> >> > users though. >> >>=20 >> >> I.e. ditch numeric suppport for numeric addresses, right? >> >>=20 >> >> Incompatible change. Do we care? >> >>=20 >> >> If we don't, we should be honest about it and mark qom-get unstable. >> >>=20 >> >> > We could introduce new properties like `devfn-str` and `devfn-int` >> >> > that alias the same value. >> >>=20 >> >> Compatibility break. If breaking compatibility is okay, I'd rather u= se >> >> the opportunity to get rid of cleverness, and go with your first opti= on. >> >>=20 >> >> > We could also introduce a new structured QAPI type. >> >>=20 >> >> What kind of type do you have in mind? >> > >> > IMHO the root cause design flaw here was to overload 'addr' as a >> > way to set both the slot number and function number, as using >> > one property for two pieces of data is a well known anti-pattern >> > we caution against. >> > >> > IOW, we should have had 'slot' and 'function' as separate properties >> > from the start. >>=20 >> Fair. >>=20 >> Our modeling of PCI is old and weird. >>=20 >> What we call "pci-device" isn't a device, it's a function, where >> function 0 sort of stands in for the device. > > Mmm, yes, interesting way of looking at it. > >> Its "addr" isn't a PCI address, it's the address of the function on its >> PCI bus, i.e. the tail of a PCI address. >>=20 >> > From a CLI POV, we could easily change 'addr' to mean only the slot >> > number, since it is always parsed in string format without the >> > magic (slot << 4) | function encoding. Then add a 'function' prop >>=20 >> In CLI, HMP and QMP string (not integer), value "5" is shorthand for >> "5.0", and means device 5, function 0. >>=20 >> We could deprecate the .FN part in favor of a new property "function". >>=20 >> Once we drop support for .FN from "addr", its name becomes even more >> misleading than it always was. > > Yes. > >> > The challenge is the impact on QMP with strict typing, as ideally >> > int format would soley represent the slot number, but today the >> > int format is encoded (slot << 4) | function. So anyone relying >> > on int format in QMP would silently have a semantic change if we >> > altered what 'addr' means.=20 >>=20 >> That's a no-go. >>=20 >> > Deprecating 'addr' entirely and adding brand new 'slot' and >> > 'function' properties would be a significant disruption to >> > a syntax which has been documented for years (decades). >>=20 >> What about this: >>=20 >> * No change to PCIDevice member @devfn: encodes slot and function as an >> integer. >>=20 >> * New "pci-device" properties "slot" and "function". "slot" sets just >> the slot bits of @devfn, and "function" sets just the function bits. >> Both default to zero, so specifying just "slot" gives you >> PCI_DEVFN(slot, 0), which makes sense. >>=20 >> * Deprecate "pci-device" property "addr" for QMP. We can keep it around >> for longer than the required grace period if that helps. >>=20 >> * Declare it legacy for CLI and HMP, with no intent to remove it. > > We can't easily keep it in CLI/HMP, while removing from QMP can we ? > As long as the property exists on the PCIDevice object, it will be > accessible everywhere. You're right. The way device_add / -device work, providing "addr" just for CLI and HMP would require gross hacks. > Perhaps keep it relatively simple and merely deprecate the string > syntax of 'addr' in QMP. That's the place where it is really ugy. > Force QMP over to only the integer syntax for 'addr', and leave > CLI/HMP accepting the (optionally dotted) string syntax. > > Mgmt apps like libvirt will have to adapt. Tedious, but actually > quite simple compared to most deprecations, as the integer syntax > can already be used with all historical QEMU versions in QMP that > mgmt apps ever need to deal with. They can unconditionally change > their code to int syntax and not worry about old/new QEMUs at all. Yes, but if management applications have to adapt anyway, why not use the opportunity to adapt to the interface we actually want, i.e. "slot" and "function"? If we add "slot" and "function", then what to do about "addr"? Options: 1. Do nothing. We provide two interfaces for setting slot / function, and no guidance on which to use. 2. We declare "addr" legacy, and recommend "slot" and "function". This tells users that using it is fine, but there's a better way. 3. We deprecate "addr" in favor of "slot and "function" without intent to remove it. Yes, we normally deprecate with intent to remove, but we don't have to. 4. We deprecate "addr" with intent to remove it. Grace period debatable. You argued against such a "significant disruption to a syntax which has been documented for years (decades)." I'm listing it for completeness.