[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4] qdev: Keep global allocation counter per bus
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [PATCH v4] qdev: Keep global allocation counter per bus |
Date: |
Tue, 18 Feb 2014 17:22:45 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
Am 06.02.2014 16:08, schrieb Markus Armbruster:
> From: Alexander Graf <address@hidden>
>
> 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 <address@hidden>
> CC: Anthony Liguori <address@hidden>
> Signed-off-by: Alexander Graf <address@hidden>
> Signed-off-by: Markus Armbruster <address@hidden>
Since Alex has it in his ppc queue,
Reviewed-by: Andreas Färber <address@hidden>
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