From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFnRf-00058O-2t for qemu-devel@nongnu.org; Tue, 18 Feb 2014 11:23:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFnRY-000158-TF for qemu-devel@nongnu.org; Tue, 18 Feb 2014 11:22:55 -0500 Received: from cantor2.suse.de ([195.135.220.15]:58126 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFnRY-000150-Hy for qemu-devel@nongnu.org; Tue, 18 Feb 2014 11:22:48 -0500 Message-ID: <530388D5.1050404@suse.de> Date: Tue, 18 Feb 2014 17:22:45 +0100 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1391699295-8381-1-git-send-email-armbru@redhat.com> In-Reply-To: <1391699295-8381-1-git-send-email-armbru@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4] qdev: Keep global allocation counter per bus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , qemu-devel@nongnu.org, Alexander Graf Cc: Paolo Bonzini , Anthony Liguori , "Michael S. Tsirkin" Am 06.02.2014 16:08, schrieb Markus Armbruster: > From: Alexander Graf >=20 > When we have 2 separate qdev devices that both create a qbus of the > same type without specifying a bus name or device name, we end up > with two buses of the same name, such as ide.0 on the Mac machines: >=20 > dev: macio-ide, id "" > bus: ide.0 > type IDE > dev: macio-ide, id "" > bus: ide.0 > type IDE >=20 > If we now spawn a device that connects to a ide.0 the last created > bus gets the device, with the first created bus inaccessible to the > command line. >=20 > After some discussion on IRC we concluded that the best quick fix way > forward for this is to make automated bus-class type based allocation > count a global counter. That's what this patch implements. With this > we instead get >=20 > dev: macio-ide, id "" > bus: ide.1 > type IDE > dev: macio-ide, id "" > bus: ide.0 > type IDE >=20 > on the example mentioned above. >=20 > This also means that if you did -device ...,bus=3Dide.0 you got a devic= e > on the first bus (the last created one) before this patch and get that > device on the second one (the first created one) now. Breaks > migration unless you change bus=3Dide.0 to bus=3Dide.1 on the destinati= on. >=20 > This is intended and makes the bus enumeration work as expected. >=20 > As per review request follows a list of otherwise affected boards and > the reasoning for the conclusion that they are ok: >=20 > target machine bus id times > ------ ------- ------ ----- >=20 > aarch64 n800 i2c-bus.0 2 > aarch64 n810 i2c-bus.0 2 > arm n800 i2c-bus.0 2 > arm n810 i2c-bus.0 2 >=20 > -> Devices are only created explicitly on one of the two buses, using > s->mpu->i2c[0], so no change to the guest. >=20 > aarch64 vexpress-a15 virtio-mmio-bus.0 4 > aarch64 vexpress-a9 virtio-mmio-bus.0 4 > aarch64 virt virtio-mmio-bus.0 32 > arm vexpress-a15 virtio-mmio-bus.0 4 > arm vexpress-a9 virtio-mmio-bus.0 4 > arm virt virtio-mmio-bus.0 32 >=20 > -> Makes -device bus=3D work for all virtio-mmio buses. Breaks > migration. Workaround for migration from old to new: specify > virtio-mmio-bus.4 or .32 respectively rather than .0 on the > destination. >=20 > aarch64 xilinx-zynq-a9 usb-bus.0 2 > arm xilinx-zynq-a9 usb-bus.0 2 > mips64el fulong2e usb-bus.0 2 >=20 > -> Normal USB operation not affected. Migration driver needs command > line to use the other bus. >=20 > i386 isapc ide.0 2 > x86_64 isapc ide.0 2 > mips mips ide.0 2 > mips64 mips ide.0 2 > mips64el mips ide.0 2 > mipsel mips ide.0 2 > ppc g3beige ide.0 2 > ppc mac99 ide.0 2 > ppc prep ide.0 2 > ppc64 g3beige ide.0 2 > ppc64 mac99 ide.0 2 > ppc64 prep ide.0 2 >=20 > -> Makes -device bus=3D work for all IDE buses. Breaks migration. > Workaround for migration from old to new: specify ide.1 rather than > ide.0 on the destination. >=20 > CC: Paolo Bonzini > CC: Anthony Liguori > Signed-off-by: Alexander Graf > Signed-off-by: Markus Armbruster Since Alex has it in his ppc queue, Reviewed-by: Andreas F=E4rber The PC change looks straightforward too and if I'm interpreting the "if (pci_enabled) { ... } else" correctly it should be covered by qom-test running -M isapc, so I'll queue it if testing succeeds. Reviews/acks/nacks still appreciated. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg