Am 06.02.2014 16:08, schrieb Markus Armbruster: > From: Alexander Graf <ag...@suse.de> > > 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: > > dev: macio-ide, id "" > bus: ide.0 > type IDE > dev: macio-ide, id "" > bus: ide.0 > type IDE > > 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. > > 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 > > dev: macio-ide, id "" > bus: ide.1 > type IDE > dev: macio-ide, id "" > bus: ide.0 > type IDE > > on the example mentioned above. > > This also means that if you did -device ...,bus=ide.0 you got a device > 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=ide.0 to bus=ide.1 on the destination. > > This is intended and makes the bus enumeration work as expected. > > As per review request follows a list of otherwise affected boards and > the reasoning for the conclusion that they are ok: > > target machine bus id times > ------ ------- ------ ----- > > aarch64 n800 i2c-bus.0 2 > aarch64 n810 i2c-bus.0 2 > arm n800 i2c-bus.0 2 > arm n810 i2c-bus.0 2 > > -> Devices are only created explicitly on one of the two buses, using > s->mpu->i2c[0], so no change to the guest. > > 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 > > -> Makes -device bus= 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. > > aarch64 xilinx-zynq-a9 usb-bus.0 2 > arm xilinx-zynq-a9 usb-bus.0 2 > mips64el fulong2e usb-bus.0 2 > > -> Normal USB operation not affected. Migration driver needs command > line to use the other bus. > > 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 > > -> Makes -device bus= work for all IDE buses. Breaks migration. > Workaround for migration from old to new: specify ide.1 rather than > ide.0 on the destination. > > CC: Paolo Bonzini <pbonz...@redhat.com> > CC: Anthony Liguori <aligu...@amazon.com> > Signed-off-by: Alexander Graf <ag...@suse.de> > Signed-off-by: Markus Armbruster <arm...@redhat.com>
Since Alex has it in his ppc queue, Reviewed-by: Andreas Färber <afaer...@suse.de> 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 -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg