qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]