From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53989) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4mmz-00087v-1p for qemu-devel@nongnu.org; Fri, 04 Dec 2015 04:36:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4mmx-0005fq-JH for qemu-devel@nongnu.org; Fri, 04 Dec 2015 04:36:28 -0500 Date: Fri, 4 Dec 2015 20:35:54 +1100 From: David Gibson Message-ID: <20151204093554.GJ9559@voom.redhat.com> References: <87bna7v9bc.fsf@blackfin.pond.sub.org> <20151204000157.GF9559@voom.redhat.com> <87mvtqy6xs.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="enLffk0M6cffIOOh" Content-Disposition: inline In-Reply-To: <87mvtqy6xs.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] Posible regressions around spapr-dr-connector property drc-connector[] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org, agraf@suse.de --enLffk0M6cffIOOh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 04, 2015 at 09:05:51AM +0100, Markus Armbruster wrote: > David Gibson writes: >=20 > > On Thu, Dec 03, 2015 at 04:30:31PM +0100, Markus Armbruster wrote: > >> 1. Before commit 94649d4 "spapr: Don't use QOM [*] syntax for DR > >> connectors", the indexes were small integers: > >>=20 > >> (qemu) info qom-tree > >> /machine (pseries-2.4-machine) > >> /unattached (container) > >> [...] > >> /device[5] (spapr-pci-host-bridge) > >> /pci@800000020000000.mmio[0] (qemu:memory-region) > >> /pci@800000020000000.mmio-alias[0] (qemu:memory-region) > >> /pci@800000020000000.io[0] (qemu:memory-region) > >> /pci@800000020000000.io-alias[0] (qemu:memory-region) > >> /pci.0 (PCI) > >> /pci@800000020000000.iommu-root[0] (qemu:memory-region) > >> /dr-connector[0] (spapr-dr-connector) > >> /dr-connector[1] (spapr-dr-connector) > >> /dr-connector[2] (spapr-dr-connector) > >> [...] > >>=20 > >> Since then, they're big ones: > >>=20 > >> /dr-connector[1073741824] (spapr-dr-connector) > >> /dr-connector[1073741825] (spapr-dr-connector) > >> /dr-connector[1073741826] (spapr-dr-connector) > >>=20 > >> The commit message doesn't quite spell out this change, and I'm > >> therefore double-checkint it's intentional. Is it? > > > > Yes, it's intentional. The small integers were arbitrarily allocated > > by the QOM magic [*] code, whereas the big integers are actually > > meaningful values (essentially the DRC's global ID for the dynamic > > reconfiguration hypervisor interfaces). >=20 > Good. >=20 > >> 2. Before commit 6c2f9a1 "qapi: Make output visitor return qnull() > >> instead of NULL", qom-get returned {}: > >>=20 > >> Since then, it returns null: > >>=20 > >> QMP> { "execute": "qom-get", "arguments": { "path": "/machine/u= nattached/device[5]/dr-connector[1073741950]", "property": "fdt" } } > >> {"return": null} > >>=20 > >> Does anyone care? > > > > Hm, I'm guessing this is a case where fdt is NULL internally. Which I >=20 > Yes. >=20 > > think will happen before a device gets hotplugged into the DRC. In > > that case null seems more correct to me than {}, since {} would also > > be what's shown for a present-but-empty device tree. >=20 > It was {} in 2.4. Changing it to null so we can distingish "nothing" > from "empty" is an incompatible change. May make sense anyway, but I > can't judge it. Strictly speaking it's an incompatible change, yes. But I find it hard to imagine anything would be relying on the {} behaviour. This property is essentially a debugging interface to start with, and the missing / empty case is examining it in a state that's unlikely to be interesting. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --enLffk0M6cffIOOh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWYV56AAoJEGw4ysog2bOSYO8P/RoqWH5NmP7YF7JXmARN9rEb Lm+SIZqDdkkSkBwd000ksdkZqsT9US4t0X+jVaMChHxFPVlRSR8u8iCPhTVm0jjs gEOMQSSJzPcfjmrbZp7dW0+MHJu+8m9gwVVBVQxONqa3pyB9+BVVE/nmOxu9/gNo PqUSzaRYFABI0ic6FKwqpvkm5p9gnGS0jnmkA+X9PJFTiXdvisco42rsPItKXKZY KDTri0odsDZ5tm/r2b9xJv31SieuIwYG3dh29uYfXBirKLVzmgNreEGXvYAL+2t3 /r06y3W93mz48Ssut6EPa+qzCiov3pE8n6orMe/Eqf3MkolzM8AEBIjmIP670+vn lflQHQQy9yl+temQFk/u2WcMLRDR4Qch09YxcjdqgBhgnzYDi2xWOLwzvOpE5Lhs EnemUH0ahlFr53sXcE5GzGt0LjXRucGxmwGxqFusJA5+fcUxgwqBHN1iYj+fwVPh mJG668ZaSzCfmM3BgSUUlMu+XBFxODunMny0oGEZgTGwUCAF+l4BV15wktzVNtD7 ZTgGwC4pxkb1KaTYGPuI5hHj7HeglD509ytJiZqIxzZlhKB8g9nrFUFMakR0pUD3 PaiDslAdOEghdWxTTHeq+zUEk48kCl+iK3GEU4juMv4wFTdmhuSb4ggjgv0IF+VA 4tSq7AX2G/Gc9GWvsN3/ =UzlO -----END PGP SIGNATURE----- --enLffk0M6cffIOOh--