* [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
@ 2013-12-20 1:41 Alexander Graf
2013-12-21 10:42 ` Markus Armbruster
0 siblings, 1 reply; 26+ messages in thread
From: Alexander Graf @ 2013-12-20 1:41 UTC (permalink / raw)
To: QEMU Developers; +Cc: Paolo Bonzini, Markus Armbruster, Anthony Liguori
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.
This is intended and makes the bus enumeration work as expected.
CC: Paolo Bonzini <pbonzini@redhat.com>
CC: Markus Armbruster <armbru@redhat.com>
CC: Anthony Liguori <aliguori@amazon.com>
Signed-off-by: Alexander Graf <agraf@suse.de>
---
v1 -> v2:
- add fix for isapc which was searching for 2 buses called "ide.0"
- explain the semantic change more in the commit message
---
hw/core/qdev.c | 20 +++++++++++++-------
hw/i386/pc_piix.c | 8 +++++++-
include/hw/qdev-core.h | 2 ++
3 files changed, 22 insertions(+), 8 deletions(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index e374a93..959130c 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -409,27 +409,33 @@ DeviceState *qdev_find_recursive(BusState *bus, const char *id)
static void qbus_realize(BusState *bus, DeviceState *parent, const char *name)
{
const char *typename = object_get_typename(OBJECT(bus));
+ BusClass *bc;
char *buf;
- int i,len;
+ int i, len, bus_id;
bus->parent = parent;
if (name) {
bus->name = g_strdup(name);
} else if (bus->parent && bus->parent->id) {
- /* parent device has id -> use it for bus name */
+ /* parent device has id -> use it plus parent-bus-id for bus name */
+ bus_id = bus->parent->num_child_bus;
+
len = strlen(bus->parent->id) + 16;
buf = g_malloc(len);
- snprintf(buf, len, "%s.%d", bus->parent->id, bus->parent->num_child_bus);
+ snprintf(buf, len, "%s.%d", bus->parent->id, bus_id);
bus->name = buf;
} else {
- /* no id -> use lowercase bus type for bus name */
+ /* no id -> use lowercase bus type plus global bus-id for bus name */
+ bc = BUS_GET_CLASS(bus);
+ bus_id = bc->automatic_ids++;
+
len = strlen(typename) + 16;
buf = g_malloc(len);
- len = snprintf(buf, len, "%s.%d", typename,
- bus->parent ? bus->parent->num_child_bus : 0);
- for (i = 0; i < len; i++)
+ len = snprintf(buf, len, "%s.%d", typename, bus_id);
+ for (i = 0; i < len; i++) {
buf[i] = qemu_tolower(buf[i]);
+ }
bus->name = buf;
}
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 4e0dae7..1d02676 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -207,10 +207,16 @@ static void pc_init1(QEMUMachineInitArgs *args,
} else {
for(i = 0; i < MAX_IDE_BUS; i++) {
ISADevice *dev;
+ char busname[] = "ide.0";
dev = isa_ide_init(isa_bus, ide_iobase[i], ide_iobase2[i],
ide_irq[i],
hd[MAX_IDE_DEVS * i], hd[MAX_IDE_DEVS * i + 1]);
- idebus[i] = qdev_get_child_bus(DEVICE(dev), "ide.0");
+ /*
+ * The ide bus name is ide.0 for the first bus and ide.1 for the
+ * second one.
+ */
+ busname[4] = '0' + i;
+ idebus[i] = qdev_get_child_bus(DEVICE(dev), busname);
}
}
diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
index f2043a6..09f8527 100644
--- a/include/hw/qdev-core.h
+++ b/include/hw/qdev-core.h
@@ -161,6 +161,8 @@ struct BusClass {
int (*reset)(BusState *bus);
/* maximum devices allowed on the bus, 0: no limit. */
int max_dev;
+ /* number of automatically allocated bus ids (e.g. ide.0) */
+ int automatic_ids;
};
typedef struct BusChild {
--
1.8.1.4
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2013-12-20 1:41 [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus Alexander Graf
@ 2013-12-21 10:42 ` Markus Armbruster
2013-12-22 13:43 ` Paolo Bonzini
0 siblings, 1 reply; 26+ messages in thread
From: Markus Armbruster @ 2013-12-21 10:42 UTC (permalink / raw)
To: Alexander Graf; +Cc: Paolo Bonzini, QEMU Developers, Anthony Liguori
Alexander Graf <agraf@suse.de> writes:
> 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.
Suggest to add: ", killing migration."
Which boards are affected? Should be listed in the commit message!
I ran a quick test for all boards that actually make it to the monitor
without special parameters or files, and survive "info qtree". 164
boards can do that, 59 refuse to start, one crashes on start, 10 make it
to the monitor but crash in info qtree. Not nice. If there's a way to
start *any* board to the monitor, please let me know.
Anyway, I found the following machines sporting non-unique bus names
before your patch:
target machine bus id times
aarch64 n800 i2c-bus.0 2
aarch64 n810 i2c-bus.0 2
aarch64 nuri i2c 9
aarch64 smdkc210 i2c 9
aarch64 vexpress-a15 virtio-mmio-bus.0 4
aarch64 vexpress-a9 virtio-mmio-bus.0 4
aarch64 virt virtio-mmio-bus.0 32
aarch64 xilinx-zynq-a9 usb-bus.0 2
aarch64 xilinx-zynq-a9 spi0 3
arm n800 i2c-bus.0 2
arm n810 i2c-bus.0 2
arm nuri i2c 9
arm smdkc210 i2c 9
arm vexpress-a15 virtio-mmio-bus.0 4
arm vexpress-a9 virtio-mmio-bus.0 4
arm virt virtio-mmio-bus.0 32
arm xilinx-zynq-a9 usb-bus.0 2
arm xilinx-zynq-a9 spi0 3
i386 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
x86_64 isapc ide.0 2
The isapc crash with v1 demonstrates that such machines need testing
with your patch.
Not yet covered:
target machine reason
aarch64 akita info qtree crashes
aarch64 borzoi info qtree crashes
aarch64 canon-a1100 refuses to start
aarch64 cheetah refuses to start
aarch64 connex refuses to start
aarch64 lm3s6965evb refuses to start
aarch64 lm3s811evb refuses to start
aarch64 mainstone refuses to start
aarch64 spitz info qtree crashes
aarch64 sx1 refuses to start
aarch64 sx1-v1 refuses to start
aarch64 terrier info qtree crashes
aarch64 tosa info qtree crashes
aarch64 verdex refuses to start
aarch64 z2 refuses to start
arm akita info qtree crashes
arm borzoi info qtree crashes
arm canon-a1100 refuses to start
arm cheetah refuses to start
arm connex refuses to start
arm lm3s6965evb refuses to start
arm lm3s811evb refuses to start
arm mainstone refuses to start
arm spitz info qtree crashes
arm sx1 refuses to start
arm sx1-v1 refuses to start
arm terrier info qtree crashes
arm tosa info qtree crashes
arm verdex refuses to start
arm z2 refuses to start
cris axis-dev88 refuses to start
i386 xenfv refuses to start
i386 xenpv refuses to start
lm32 milkymist refuses to start
m68k an5206 refuses to start
m68k mcf5208evb refuses to start
mips magnum refuses to start
mips malta refuses to start
mips mipssim refuses to start
mips pica61 refuses to start
mips64 magnum refuses to start
mips64 malta refuses to start
mips64 mipssim refuses to start
mips64 pica61 refuses to start
mips64el fulong2e refuses to start
mips64el magnum refuses to start
mips64el malta refuses to start
mips64el mipssim refuses to start
mips64el pica61 refuses to start
mipsel magnum refuses to start
mipsel malta refuses to start
mipsel mipssim refuses to start
mipsel pica61 refuses to start
ppc ref405ep refuses to start
ppc taihu refuses to start
ppc64 ref405ep refuses to start
ppc64 taihu refuses to start
ppcemb g3beige refuses to start
ppcemb mac99 refuses to start
ppcemb mpc8544ds refuses to start
ppcemb ppce500 refuses to start
ppcemb prep refuses to start
ppcemb ref405ep refuses to start
ppcemb taihu refuses to start
sh4 shix refuses to start
sh4eb shix refuses to start
sparc leon3_generic refuses to start
unicore32 puv3 crashes on startup
x86_64 xenfv refuses to start
x86_64 xenpv refuses to start
>
> This is intended and makes the bus enumeration work as expected.
>
> CC: Paolo Bonzini <pbonzini@redhat.com>
> CC: Markus Armbruster <armbru@redhat.com>
> CC: Anthony Liguori <aliguori@amazon.com>
> Signed-off-by: Alexander Graf <agraf@suse.de>
>
> ---
>
> v1 -> v2:
>
> - add fix for isapc which was searching for 2 buses called "ide.0"
Yes, this version no longer crashes on startup. The secondary
controller's bus gets renamed to "ide.1".
> - explain the semantic change more in the commit message
Patch looks good to me, but I'd recommend more thorough testing, as
outlined above.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2013-12-21 10:42 ` Markus Armbruster
@ 2013-12-22 13:43 ` Paolo Bonzini
2014-01-07 15:12 ` Markus Armbruster
0 siblings, 1 reply; 26+ messages in thread
From: Paolo Bonzini @ 2013-12-22 13:43 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Alexander Graf, Anthony Liguori, QEMU Developers
Il 21/12/2013 11:42, Markus Armbruster ha scritto:
> Suggest to add: ", killing migration."
Not good. But perhaps we can give a reason for this 2.0 thing.
It is certainly nice to schedule incompatible changes for obscure
machine types every 2 years.
> Which boards are affected? Should be listed in the commit message!
>
> I ran a quick test for all boards that actually make it to the monitor
> without special parameters or files, and survive "info qtree". 164
> boards can do that, 59 refuse to start, one crashes on start, 10 make it
> to the monitor but crash in info qtree. Not nice. If there's a way to
> start *any* board to the monitor, please let me know.
"-machine accel=qtest" probably helps with those that refuse to start.
Paolo
> Anyway, I found the following machines sporting non-unique bus names
> before your patch:
>
> target machine bus id times
> aarch64 n800 i2c-bus.0 2
> aarch64 n810 i2c-bus.0 2
> aarch64 nuri i2c 9
> aarch64 smdkc210 i2c 9
> aarch64 vexpress-a15 virtio-mmio-bus.0 4
> aarch64 vexpress-a9 virtio-mmio-bus.0 4
> aarch64 virt virtio-mmio-bus.0 32
> aarch64 xilinx-zynq-a9 usb-bus.0 2
> aarch64 xilinx-zynq-a9 spi0 3
> arm n800 i2c-bus.0 2
> arm n810 i2c-bus.0 2
> arm nuri i2c 9
> arm smdkc210 i2c 9
> arm vexpress-a15 virtio-mmio-bus.0 4
> arm vexpress-a9 virtio-mmio-bus.0 4
> arm virt virtio-mmio-bus.0 32
> arm xilinx-zynq-a9 usb-bus.0 2
> arm xilinx-zynq-a9 spi0 3
> i386 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
> x86_64 isapc ide.0 2
>
> The isapc crash with v1 demonstrates that such machines need testing
> with your patch.
>
> Not yet covered:
>
> target machine reason
> aarch64 akita info qtree crashes
> aarch64 borzoi info qtree crashes
> aarch64 canon-a1100 refuses to start
> aarch64 cheetah refuses to start
> aarch64 connex refuses to start
> aarch64 lm3s6965evb refuses to start
> aarch64 lm3s811evb refuses to start
> aarch64 mainstone refuses to start
> aarch64 spitz info qtree crashes
> aarch64 sx1 refuses to start
> aarch64 sx1-v1 refuses to start
> aarch64 terrier info qtree crashes
> aarch64 tosa info qtree crashes
> aarch64 verdex refuses to start
> aarch64 z2 refuses to start
> arm akita info qtree crashes
> arm borzoi info qtree crashes
> arm canon-a1100 refuses to start
> arm cheetah refuses to start
> arm connex refuses to start
> arm lm3s6965evb refuses to start
> arm lm3s811evb refuses to start
> arm mainstone refuses to start
> arm spitz info qtree crashes
> arm sx1 refuses to start
> arm sx1-v1 refuses to start
> arm terrier info qtree crashes
> arm tosa info qtree crashes
> arm verdex refuses to start
> arm z2 refuses to start
> cris axis-dev88 refuses to start
> i386 xenfv refuses to start
> i386 xenpv refuses to start
> lm32 milkymist refuses to start
> m68k an5206 refuses to start
> m68k mcf5208evb refuses to start
> mips magnum refuses to start
> mips malta refuses to start
> mips mipssim refuses to start
> mips pica61 refuses to start
> mips64 magnum refuses to start
> mips64 malta refuses to start
> mips64 mipssim refuses to start
> mips64 pica61 refuses to start
> mips64el fulong2e refuses to start
> mips64el magnum refuses to start
> mips64el malta refuses to start
> mips64el mipssim refuses to start
> mips64el pica61 refuses to start
> mipsel magnum refuses to start
> mipsel malta refuses to start
> mipsel mipssim refuses to start
> mipsel pica61 refuses to start
> ppc ref405ep refuses to start
> ppc taihu refuses to start
> ppc64 ref405ep refuses to start
> ppc64 taihu refuses to start
> ppcemb g3beige refuses to start
> ppcemb mac99 refuses to start
> ppcemb mpc8544ds refuses to start
> ppcemb ppce500 refuses to start
> ppcemb prep refuses to start
> ppcemb ref405ep refuses to start
> ppcemb taihu refuses to start
> sh4 shix refuses to start
> sh4eb shix refuses to start
> sparc leon3_generic refuses to start
> unicore32 puv3 crashes on startup
> x86_64 xenfv refuses to start
> x86_64 xenpv refuses to start
>
>>
>> This is intended and makes the bus enumeration work as expected.
>>
>> CC: Paolo Bonzini <pbonzini@redhat.com>
>> CC: Markus Armbruster <armbru@redhat.com>
>> CC: Anthony Liguori <aliguori@amazon.com>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>
>> ---
>>
>> v1 -> v2:
>>
>> - add fix for isapc which was searching for 2 buses called "ide.0"
>
> Yes, this version no longer crashes on startup. The secondary
> controller's bus gets renamed to "ide.1".
>
>> - explain the semantic change more in the commit message
>
> Patch looks good to me, but I'd recommend more thorough testing, as
> outlined above.
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2013-12-22 13:43 ` Paolo Bonzini
@ 2014-01-07 15:12 ` Markus Armbruster
2014-01-07 16:59 ` Paolo Bonzini
0 siblings, 1 reply; 26+ messages in thread
From: Markus Armbruster @ 2014-01-07 15:12 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Alexander Graf, Anthony Liguori, QEMU Developers
Paolo Bonzini <pbonzini@redhat.com> writes:
> Il 21/12/2013 11:42, Markus Armbruster ha scritto:
>> Suggest to add: ", killing migration."
>
> Not good. But perhaps we can give a reason for this 2.0 thing.
>
> It is certainly nice to schedule incompatible changes for obscure
> machine types every 2 years.
>
>> Which boards are affected? Should be listed in the commit message!
>>
>> I ran a quick test for all boards that actually make it to the monitor
>> without special parameters or files, and survive "info qtree". 164
>> boards can do that, 59 refuse to start, one crashes on start, 10 make it
>> to the monitor but crash in info qtree. Not nice. If there's a way to
>> start *any* board to the monitor, please let me know.
>
> "-machine accel=qtest" probably helps with those that refuse to start.
Yes, that helps some.
Non-unique bus names:
target machine bus id times
aarch64 connex dummy 2
i2c 2
ssi 2
aarch64 mainstone dummy 2
i2c 2
ssi 3
aarch64 n800 i2c-bus.0 2
aarch64 n810 i2c-bus.0 2
aarch64 nuri i2c 9
aarch64 smdkc210 i2c 9
aarch64 verdex dummy 2
i2c 2
ssi 3
aarch64 vexpress-a15 virtio-mmio-bus.0 4
aarch64 vexpress-a9 virtio-mmio-bus.0 4
aarch64 virt virtio-mmio-bus.0 32
aarch64 xilinx-zynq-a9 spi0 3
usb-bus.0 2
aarch64 z2 dummy 2
i2c 2
ssi 3
arm connex dummy 2
i2c 2
ssi 2
arm mainstone dummy 2
i2c 2
ssi 3
arm n800 i2c-bus.0 2
arm n810 i2c-bus.0 2
arm nuri i2c 9
arm smdkc210 i2c 9
arm verdex dummy 2
i2c 2
ssi 3
arm vexpress-a15 virtio-mmio-bus.0 4
arm vexpress-a9 virtio-mmio-bus.0 4
arm virt virtio-mmio-bus.0 32
arm xilinx-zynq-a9 spi0 3
usb-bus.0 2
arm z2 dummy 2
i2c 2
ssi 3
i386 isapc ide.0 2
mips mips ide.0 2
mips64 mips ide.0 2
mips64el fulong2e usb-bus.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
s390x s390-virtio virtio-bus 2
x86_64 isapc ide.0 2
Machines not covered:
target machine reason
aarch64 akita info qtree crashes
aarch64 borzoi info qtree crashes
aarch64 spitz info qtree crashes
aarch64 terrier info qtree crashes
aarch64 tosa info qtree crashes
arm akita info qtree crashes
arm borzoi info qtree crashes
arm spitz info qtree crashes
arm terrier info qtree crashes
arm tosa info qtree crashes
cris axis-dev88 info qtree crashes
i386 xenfv refuses to start (1)
i386 xenpv refuses to start (2)
ppcemb g3beige refuses to start (3)
ppcemb mac99 refuses to start (3)
ppcemb mpc8544ds refuses to start (4)
ppcemb ppce500 refuses to start (4)
ppcemb prep refuses to start (3)
ppcemb ref405ep refuses to start (5)
ppcemb taihu refuses to start (5)
x86_64 xenfv refuses to start (1)
x86_64 xenpv refuses to start (2)
(1) xen be core: can't connect to xenstored
Expected, as it's not running under Xen
(2) Segmentation fault
(3) Unable to find PowerPC CPU definition
(4) Unable to initialize CPU!
(5) Unable to find PowerPC 405ep CPU definition
[...]
>> Patch looks good to me, but I'd recommend more thorough testing, as
>> outlined above.
Still do.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-07 15:12 ` Markus Armbruster
@ 2014-01-07 16:59 ` Paolo Bonzini
2014-01-07 17:34 ` Markus Armbruster
2014-01-08 3:07 ` Peter Crosthwaite
0 siblings, 2 replies; 26+ messages in thread
From: Paolo Bonzini @ 2014-01-07 16:59 UTC (permalink / raw)
To: Markus Armbruster, Peter Crosthwaite
Cc: Alexander Graf, Anthony Liguori, QEMU Developers
Il 07/01/2014 16:12, Markus Armbruster ha scritto:
> aarch64 akita info qtree crashes
> aarch64 borzoi info qtree crashes
> aarch64 spitz info qtree crashes
> aarch64 terrier info qtree crashes
> aarch64 tosa info qtree crashes
> arm akita info qtree crashes
> arm borzoi info qtree crashes
> arm spitz info qtree crashes
> arm terrier info qtree crashes
> arm tosa info qtree crashes
> cris axis-dev88 info qtree crashes
The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
2013-06-18). Should probably be reverted.
Paolo
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-07 16:59 ` Paolo Bonzini
@ 2014-01-07 17:34 ` Markus Armbruster
2014-01-08 14:04 ` Paolo Bonzini
2014-01-08 3:07 ` Peter Crosthwaite
1 sibling, 1 reply; 26+ messages in thread
From: Markus Armbruster @ 2014-01-07 17:34 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Peter Crosthwaite, Alexander Graf, Anthony Liguori,
QEMU Developers
Paolo Bonzini <pbonzini@redhat.com> writes:
> Il 07/01/2014 16:12, Markus Armbruster ha scritto:
>> aarch64 akita info qtree crashes
>> aarch64 borzoi info qtree crashes
>> aarch64 spitz info qtree crashes
>> aarch64 terrier info qtree crashes
>> aarch64 tosa info qtree crashes
>> arm akita info qtree crashes
>> arm borzoi info qtree crashes
>> arm spitz info qtree crashes
>> arm terrier info qtree crashes
>> arm tosa info qtree crashes
>> cris axis-dev88 info qtree crashes
>
> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
> 2013-06-18). Should probably be reverted.
Yes, reverting that one makes these machines work again. Updated
results:
Non-unique bus names:
target machine bus id times
aarch64 akita dummy 2
i2c 2
ssi 3
aarch64 borzoi dummy 2
i2c 2
ssi 3
aarch64 connex dummy 2
i2c 2
ssi 2
aarch64 mainstone dummy 2
i2c 2
ssi 3
aarch64 n800 i2c-bus.0 2
aarch64 n810 i2c-bus.0 2
aarch64 nuri i2c 9
aarch64 smdkc210 i2c 9
aarch64 spitz dummy 2
i2c 2
ssi 3
aarch64 terrier dummy 2
i2c 2
ssi 3
aarch64 tosa dummy 2
i2c 2
ssi 2
aarch64 verdex dummy 2
i2c 2
ssi 3
aarch64 vexpress-a15 virtio-mmio-bus.0 4
aarch64 vexpress-a9 virtio-mmio-bus.0 4
aarch64 virt virtio-mmio-bus.0 32
aarch64 xilinx-zynq-a9 spi0 3
usb-bus.0 2
aarch64 z2 dummy 2
i2c 2
ssi 3
arm akita dummy 2
i2c 2
ssi 3
arm borzoi dummy 2
i2c 2
ssi 3
arm connex dummy 2
i2c 2
ssi 2
arm mainstone dummy 2
i2c 2
ssi 3
arm n800 i2c-bus.0 2
arm n810 i2c-bus.0 2
arm nuri i2c 9
arm smdkc210 i2c 9
arm spitz dummy 2
i2c 2
ssi 3
arm terrier dummy 2
i2c 2
ssi 3
arm tosa dummy 2
i2c 2
ssi 2
arm verdex dummy 2
i2c 2
ssi 3
arm vexpress-a15 virtio-mmio-bus.0 4
arm vexpress-a9 virtio-mmio-bus.0 4
arm virt virtio-mmio-bus.0 32
arm xilinx-zynq-a9 spi0 3
usb-bus.0 2
arm z2 dummy 2
i2c 2
ssi 3
i386 isapc ide.0 2
mips mips ide.0 2
mips64 mips ide.0 2
mips64el fulong2e usb-bus.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
s390x s390-virtio virtio-bus 2
x86_64 isapc ide.0 2
Machines not covered:
target machine reason
i386 xenfv refuses to start (1)
i386 xenpv refuses to start (2)
ppcemb g3beige refuses to start (3)
ppcemb mac99 refuses to start (3)
ppcemb mpc8544ds refuses to start (4)
ppcemb ppce500 refuses to start (4)
ppcemb prep refuses to start (3)
ppcemb ref405ep refuses to start (5)
ppcemb taihu refuses to start (5)
x86_64 xenfv refuses to start (1)
x86_64 xenpv refuses to start (2)
(1) xen be core: can't connect to xenstored
Expected, as it's not running under Xen
(2) Segmentation fault
(3) Unable to find PowerPC CPU definition
(4) Unable to initialize CPU!
(5) Unable to find PowerPC 405ep CPU definition
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-07 16:59 ` Paolo Bonzini
2014-01-07 17:34 ` Markus Armbruster
@ 2014-01-08 3:07 ` Peter Crosthwaite
2014-01-08 4:24 ` Andreas Färber
` (2 more replies)
1 sibling, 3 replies; 26+ messages in thread
From: Peter Crosthwaite @ 2014-01-08 3:07 UTC (permalink / raw)
To: Paolo Bonzini, Andreas Färber
Cc: QEMU Developers, Markus Armbruster, Anthony Liguori,
Alexander Graf
On Wed, Jan 8, 2014 at 2:59 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 07/01/2014 16:12, Markus Armbruster ha scritto:
>> aarch64 akita info qtree crashes
>> aarch64 borzoi info qtree crashes
>> aarch64 spitz info qtree crashes
>> aarch64 terrier info qtree crashes
>> aarch64 tosa info qtree crashes
>> arm akita info qtree crashes
>> arm borzoi info qtree crashes
>> arm spitz info qtree crashes
>> arm terrier info qtree crashes
>> arm tosa info qtree crashes
>> cris axis-dev88 info qtree crashes
>
> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
> 2013-06-18). Should probably be reverted.
>
Prefer not, under no reasonable definition is NAND a sysbus device.
Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
qtree that TYPE_DEVICE is not?
Regards,
Peter
> Paolo
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 3:07 ` Peter Crosthwaite
@ 2014-01-08 4:24 ` Andreas Färber
2014-01-08 8:00 ` Markus Armbruster
2014-01-08 10:11 ` Peter Maydell
2014-01-08 8:13 ` Markus Armbruster
2014-01-08 11:02 ` Paolo Bonzini
2 siblings, 2 replies; 26+ messages in thread
From: Andreas Färber @ 2014-01-08 4:24 UTC (permalink / raw)
To: Peter Crosthwaite, Igor Mammedov, Markus Armbruster,
Peter Maydell
Cc: Paolo Bonzini, QEMU Developers, Anthony Liguori, Alexander Graf
Am 08.01.2014 04:07, schrieb Peter Crosthwaite:
> On Wed, Jan 8, 2014 at 2:59 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 07/01/2014 16:12, Markus Armbruster ha scritto:
>>> aarch64 akita info qtree crashes
>>> aarch64 borzoi info qtree crashes
>>> aarch64 spitz info qtree crashes
>>> aarch64 terrier info qtree crashes
>>> aarch64 tosa info qtree crashes
>>> arm akita info qtree crashes
>>> arm borzoi info qtree crashes
>>> arm spitz info qtree crashes
>>> arm terrier info qtree crashes
>>> arm tosa info qtree crashes
>>> cris axis-dev88 info qtree crashes
>>
>> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
>> 2013-06-18). Should probably be reverted.
>>
>
> Prefer not, under no reasonable definition is NAND a sysbus device.
> Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
> qtree that TYPE_DEVICE is not?
Not fully aware of the context yet, but my response to complaints about
info qtree, whether here or from Igor, will be to simply drop it.
Anthony has clearly stated on a KVM call that we should not design code
to please info qtree but to use the new QOM paradigms. If people don't
listen, we must take qdev stuff away for people to realize it - 2.0 is
certainly a good point in time. And I had already informally posted a
qom-tree Python script to the list that I can turn into a formal patch.
My plan was to first extend the qom-test to assure that all machines'
properties can be qom-get'ed crash-free, but we can of course skip such
safety precautions if that helps avoid weird workarounds.
As a reminder, the CPU is not a SysBus device either (ICC on x86, device
elsewhere) and I certainly don't want to make it one, especially now
that we're about to refactor AddressSpaces.
Regards,
Andreas
P.S. PMM, reading aarch64 above in the context of machines, I don't see
a single check-qtest-aarch64-y line in tests/Makefile! Please enable
qom-test if qemu-system-aarch64 is already available. Thought you just
said it would be linux-user only for 2.0 though?
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 4:24 ` Andreas Färber
@ 2014-01-08 8:00 ` Markus Armbruster
2014-01-08 10:11 ` Peter Maydell
1 sibling, 0 replies; 26+ messages in thread
From: Markus Armbruster @ 2014-01-08 8:00 UTC (permalink / raw)
To: Andreas Färber
Cc: Peter Maydell, Peter Crosthwaite, QEMU Developers, Alexander Graf,
Anthony Liguori, Paolo Bonzini, Igor Mammedov
Andreas Färber <afaerber@suse.de> writes:
> Am 08.01.2014 04:07, schrieb Peter Crosthwaite:
>> On Wed, Jan 8, 2014 at 2:59 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> Il 07/01/2014 16:12, Markus Armbruster ha scritto:
>>>> aarch64 akita info qtree crashes
>>>> aarch64 borzoi info qtree crashes
>>>> aarch64 spitz info qtree crashes
>>>> aarch64 terrier info qtree crashes
>>>> aarch64 tosa info qtree crashes
>>>> arm akita info qtree crashes
>>>> arm borzoi info qtree crashes
>>>> arm spitz info qtree crashes
>>>> arm terrier info qtree crashes
>>>> arm tosa info qtree crashes
>>>> cris axis-dev88 info qtree crashes
>>>
>>> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
>>> 2013-06-18). Should probably be reverted.
>>>
>>
>> Prefer not, under no reasonable definition is NAND a sysbus device.
>> Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
>> qtree that TYPE_DEVICE is not?
>
> Not fully aware of the context yet, but my response to complaints about
> info qtree, whether here or from Igor, will be to simply drop it.
>
> Anthony has clearly stated on a KVM call that we should not design code
> to please info qtree but to use the new QOM paradigms. If people don't
> listen, we must take qdev stuff away for people to realize it - 2.0 is
> certainly a good point in time. And I had already informally posted a
> qom-tree Python script to the list that I can turn into a formal patch.
>
> My plan was to first extend the qom-test to assure that all machines'
> properties can be qom-get'ed crash-free, but we can of course skip such
> safety precautions if that helps avoid weird workarounds.
>
> As a reminder, the CPU is not a SysBus device either (ICC on x86, device
> elsewhere) and I certainly don't want to make it one, especially now
> that we're about to refactor AddressSpaces.
No matter how much you want to retire a monitor command, until you've
retired it, a crash bug is a crash bug. Crash bugs need fixing a.s.a.p.
In this case, we have a safe and quick fix: revert the (recent!) patch
that broke it.
I object to retiring "info qtree" before a replacement is available. In
my personal opinion, a bunch of python scripts is not a replacement.
They may be okay for developers, but hardly for users. We need a HMP
command to inspect the machine. Device IDs, in particular, but also
other properties.
"info qtree" has always been incomplete, because it can only show
qdevified devices. Restricting it further to the subtree rooted at the
main system bus that is connected via qbus edges could be okay. If it
helps, which isn't obvious to me, but I'm happy to leave that to you.
[...]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 3:07 ` Peter Crosthwaite
2014-01-08 4:24 ` Andreas Färber
@ 2014-01-08 8:13 ` Markus Armbruster
2014-01-08 8:26 ` Peter Crosthwaite
2014-01-08 13:40 ` Andreas Färber
2014-01-08 11:02 ` Paolo Bonzini
2 siblings, 2 replies; 26+ messages in thread
From: Markus Armbruster @ 2014-01-08 8:13 UTC (permalink / raw)
To: Peter Crosthwaite
Cc: Paolo Bonzini, Andreas Färber, QEMU Developers,
Anthony Liguori, Alexander Graf
Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:
> On Wed, Jan 8, 2014 at 2:59 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 07/01/2014 16:12, Markus Armbruster ha scritto:
>>> aarch64 akita info qtree crashes
>>> aarch64 borzoi info qtree crashes
>>> aarch64 spitz info qtree crashes
>>> aarch64 terrier info qtree crashes
>>> aarch64 tosa info qtree crashes
>>> arm akita info qtree crashes
>>> arm borzoi info qtree crashes
>>> arm spitz info qtree crashes
>>> arm terrier info qtree crashes
>>> arm tosa info qtree crashes
>>> cris axis-dev88 info qtree crashes
>>
>> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
>> 2013-06-18). Should probably be reverted.
>>
>
> Prefer not, under no reasonable definition is NAND a sysbus device.
> Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
> qtree that TYPE_DEVICE is not?
Maybe, but our definition of sysbus has never been reasonable :)
Qdev, as designed by Paul Brook, assumed the parent of a qdev is always
a qbus and vice versa. With the exception of the root, which has no
parent, and is a sysbus, commonly the only one.
A PCI qdev plugs into a PCI qbus, an USB qdev plugs into an USB qbus,
and so forth. Any qdev that doesn't really plug into a bus was made a
"sysbus device" by fiat. "Sysbus" is a catchall, no more. In
particular, it's not a bus in the hardware sense.
This "everything plugs into exactly one bus" assumption is of course a
gross oversimplification, and we've been working on overcoming it for
quite some time. It has become possible to define qdevs that aren't
connected to a qbus. A TYPE_DEVICE isn't.
That's progress. But progress isn't justification for not fixing crash
bugs in monitor commands.
Either you fix "info qtree" to cope with your change to the device
graph, or the change needs to be reverted until somebody fixes it or it
goes away.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 8:13 ` Markus Armbruster
@ 2014-01-08 8:26 ` Peter Crosthwaite
2014-01-08 13:40 ` Andreas Färber
1 sibling, 0 replies; 26+ messages in thread
From: Peter Crosthwaite @ 2014-01-08 8:26 UTC (permalink / raw)
To: Markus Armbruster
Cc: Paolo Bonzini, Andreas Färber, QEMU Developers,
Anthony Liguori, Alexander Graf
On Wed, Jan 8, 2014 at 6:13 PM, Markus Armbruster <armbru@redhat.com> wrote:
>
> Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:
>
> > On Wed, Jan 8, 2014 at 2:59 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >> Il 07/01/2014 16:12, Markus Armbruster ha scritto:
> >>> aarch64 akita info qtree crashes
> >>> aarch64 borzoi info qtree crashes
> >>> aarch64 spitz info qtree crashes
> >>> aarch64 terrier info qtree crashes
> >>> aarch64 tosa info qtree crashes
> >>> arm akita info qtree crashes
> >>> arm borzoi info qtree crashes
> >>> arm spitz info qtree crashes
> >>> arm terrier info qtree crashes
> >>> arm tosa info qtree crashes
> >>> cris axis-dev88 info qtree crashes
> >>
> >> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
> >> 2013-06-18). Should probably be reverted.
> >>
> >
> > Prefer not, under no reasonable definition is NAND a sysbus device.
> > Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
> > qtree that TYPE_DEVICE is not?
>
> Maybe, but our definition of sysbus has never been reasonable :)
>
FWIW my def "is a device with at least one memory mapped io region,
optionally with interrupts".
> Qdev, as designed by Paul Brook, assumed the parent of a qdev is always
> a qbus and vice versa. With the exception of the root, which has no
> parent, and is a sysbus, commonly the only one.
>
> A PCI qdev plugs into a PCI qbus, an USB qdev plugs into an USB qbus,
> and so forth. Any qdev that doesn't really plug into a bus was made a
> "sysbus device" by fiat. "Sysbus" is a catchall, no more. In
> particular, it's not a bus in the hardware sense.
>
Can we catch-all, and in qdev itself parent any orphans to the root
sysbus? If so is this init or realize stage?
>
> This "everything plugs into exactly one bus" assumption is of course a
> gross oversimplification, and we've been working on overcoming it for
> quite some time. It has become possible to define qdevs that aren't
> connected to a qbus. A TYPE_DEVICE isn't.
>
> That's progress. But progress isn't justification for not fixing crash
> bugs in monitor commands.
>
> Either you fix "info qtree" to cope with your change to the device
> graph, or the change needs to be reverted until somebody fixes it or it
> goes away.
>
Yes, I'm looking for a real answer here. Just getting my head around
the problem at this minute. Thanks for the write up.
Perhaps, long term the solution is to BUSify the NAND BUS itself:
{
.name = TYPE_ONFI_BUS
.parent = TYPE_BUS
}
{
.name = TYPE_ONFI
.parent = TYPE_DEVICE
}
Regards,
Peter
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 4:24 ` Andreas Färber
2014-01-08 8:00 ` Markus Armbruster
@ 2014-01-08 10:11 ` Peter Maydell
1 sibling, 0 replies; 26+ messages in thread
From: Peter Maydell @ 2014-01-08 10:11 UTC (permalink / raw)
To: Andreas Färber
Cc: Alexander Graf, Peter Crosthwaite, QEMU Developers,
Markus Armbruster, Anthony Liguori, Paolo Bonzini, Igor Mammedov
On 8 January 2014 04:24, Andreas Färber <afaerber@suse.de> wrote:
> P.S. PMM, reading aarch64 above in the context of machines, I don't see
> a single check-qtest-aarch64-y line in tests/Makefile! Please enable
> qom-test if qemu-system-aarch64 is already available. Thought you just
> said it would be linux-user only for 2.0 though?
qemu-system-aarch64 will exist in 2.0 primarily for KVM's
benefit (you can run a -cpu host -mach virt VM with it). It
also supports all the 32 bit CPUs and boards as a drop-in
equivalent to qemu-system-arm.
I'll look at adding the tests.
thanks
-- PMM
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 3:07 ` Peter Crosthwaite
2014-01-08 4:24 ` Andreas Färber
2014-01-08 8:13 ` Markus Armbruster
@ 2014-01-08 11:02 ` Paolo Bonzini
2014-01-08 13:53 ` Andreas Färber
2 siblings, 1 reply; 26+ messages in thread
From: Paolo Bonzini @ 2014-01-08 11:02 UTC (permalink / raw)
To: Peter Crosthwaite
Cc: Alexander Graf, Andreas Färber, QEMU Developers,
Anthony Liguori, Markus Armbruster
Il 08/01/2014 04:07, Peter Crosthwaite ha scritto:
>> > The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
>> > 2013-06-18). Should probably be reverted.
>> >
> Prefer not, under no reasonable definition is NAND a sysbus device.
> Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
> qtree that TYPE_DEVICE is not?
The device's dev->parent_bus is main_system_bus.
Paolo
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 8:13 ` Markus Armbruster
2014-01-08 8:26 ` Peter Crosthwaite
@ 2014-01-08 13:40 ` Andreas Färber
2014-01-08 13:47 ` Paolo Bonzini
1 sibling, 1 reply; 26+ messages in thread
From: Andreas Färber @ 2014-01-08 13:40 UTC (permalink / raw)
To: Markus Armbruster, Peter Crosthwaite
Cc: Paolo Bonzini, QEMU Developers, Anthony Liguori, Alexander Graf
Am 08.01.2014 09:13, schrieb Markus Armbruster:
> Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:
>
>> On Wed, Jan 8, 2014 at 2:59 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> Il 07/01/2014 16:12, Markus Armbruster ha scritto:
>>>> aarch64 akita info qtree crashes
>>>> aarch64 borzoi info qtree crashes
>>>> aarch64 spitz info qtree crashes
>>>> aarch64 terrier info qtree crashes
>>>> aarch64 tosa info qtree crashes
>>>> arm akita info qtree crashes
>>>> arm borzoi info qtree crashes
>>>> arm spitz info qtree crashes
>>>> arm terrier info qtree crashes
>>>> arm tosa info qtree crashes
>>>> cris axis-dev88 info qtree crashes
>>>
>>> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
>>> 2013-06-18). Should probably be reverted.
>>>
>>
>> Prefer not, under no reasonable definition is NAND a sysbus device.
>> Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
>> qtree that TYPE_DEVICE is not?
>
> Maybe, but our definition of sysbus has never been reasonable :)
>
> Qdev, as designed by Paul Brook, assumed the parent of a qdev is always
> a qbus and vice versa. With the exception of the root, which has no
> parent, and is a sysbus, commonly the only one.
>
> A PCI qdev plugs into a PCI qbus, an USB qdev plugs into an USB qbus,
> and so forth. Any qdev that doesn't really plug into a bus was made a
> "sysbus device" by fiat. "Sysbus" is a catchall, no more. In
> particular, it's not a bus in the hardware sense.
>
> This "everything plugs into exactly one bus" assumption is of course a
> gross oversimplification, and we've been working on overcoming it for
> quite some time. It has become possible to define qdevs that aren't
> connected to a qbus. A TYPE_DEVICE isn't.
>
> That's progress. But progress isn't justification for not fixing crash
> bugs in monitor commands.
>
> Either you fix "info qtree" to cope with your change to the device
> graph, or the change needs to be reverted until somebody fixes it or it
> goes away.
Sharing a backtrace would be a start, rather than just throwing around
the word "crash" to justify reverting patches. :)
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 13:40 ` Andreas Färber
@ 2014-01-08 13:47 ` Paolo Bonzini
2014-01-10 7:50 ` Peter Crosthwaite
0 siblings, 1 reply; 26+ messages in thread
From: Paolo Bonzini @ 2014-01-08 13:47 UTC (permalink / raw)
To: Andreas Färber
Cc: Alexander Graf, Peter Crosthwaite, Markus Armbruster,
Anthony Liguori, QEMU Developers
Il 08/01/2014 14:40, Andreas Färber ha scritto:
> > Either you fix "info qtree" to cope with your change to the device
> > graph, or the change needs to be reverted until somebody fixes it or it
> > goes away.
> Sharing a backtrace would be a start, rather than just throwing around
> the word "crash" to justify reverting patches. :)
I mentioned the root cause in the previous message: a Device cannot be
added to main_system_bus, but that's what the patch does. The fix isn't
trivial, because most of the affected board are not even qdevified.
Paolo
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 11:02 ` Paolo Bonzini
@ 2014-01-08 13:53 ` Andreas Färber
2014-01-08 14:07 ` Paolo Bonzini
0 siblings, 1 reply; 26+ messages in thread
From: Andreas Färber @ 2014-01-08 13:53 UTC (permalink / raw)
To: Paolo Bonzini, Peter Crosthwaite
Cc: Alexander Graf, QEMU Developers, Anthony Liguori,
Markus Armbruster
Am 08.01.2014 12:02, schrieb Paolo Bonzini:
> Il 08/01/2014 04:07, Peter Crosthwaite ha scritto:
>>>> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
>>>> 2013-06-18). Should probably be reverted.
>>>>
>> Prefer not, under no reasonable definition is NAND a sysbus device.
>> Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
>> qtree that TYPE_DEVICE is not?
>
> The device's dev->parent_bus is main_system_bus.
Meaning in turn that qdev_create() was used rather then object_new().
Simple fix. :)
Possibly already in my pending qom-next pull?
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-07 17:34 ` Markus Armbruster
@ 2014-01-08 14:04 ` Paolo Bonzini
2014-01-08 14:35 ` Markus Armbruster
0 siblings, 1 reply; 26+ messages in thread
From: Paolo Bonzini @ 2014-01-08 14:04 UTC (permalink / raw)
To: Markus Armbruster
Cc: Peter Crosthwaite, Alexander Graf, Anthony Liguori,
QEMU Developers
Leaving only those that will be affected by the patch:
Il 07/01/2014 18:34, Markus Armbruster ha scritto:
> 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 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
With Alex's patch we get the ability to plug the device in a particular
slot. If anyone was using virtio-mmio-bus.0 explicitly, they get the
first slot instead of the 4th or 32nd. Bugfix.
> aarch64 xilinx-zynq-a9 usb-bus.0 2
> arm xilinx-zynq-a9 usb-bus.0 2
> mips64el fulong2e usb-bus.0 2
With Alex's patch we get the ability to plug the device in a particular
controller. If anyone was using usb-bus.0 explicitly, they get the
"other" controller. Guest visible change and not really a bugfix but it
doesn't break working configurations (the position of USB devices should
not be part of a device tree or firmware blob). It may break migration.
> i386 isapc ide.0 2
> x86_64 isapc ide.0 2
(Ugly) fix in Alex's patch. The macio approach (using QOM children) is
better. No need for a perfect fix now.
> mips mips ide.0 2
> mips64 mips ide.0 2
> mips64el mips ide.0 2
> mipsel mips ide.0 2
Not affected, the bus is not stored anywhere.
> 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
Trusting Alex's tests here.
Paolo
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 13:53 ` Andreas Färber
@ 2014-01-08 14:07 ` Paolo Bonzini
0 siblings, 0 replies; 26+ messages in thread
From: Paolo Bonzini @ 2014-01-08 14:07 UTC (permalink / raw)
To: Andreas Färber
Cc: Markus Armbruster, Peter Crosthwaite, Alexander Graf,
Anthony Liguori, QEMU Developers
Il 08/01/2014 14:53, Andreas Färber ha scritto:
> Am 08.01.2014 12:02, schrieb Paolo Bonzini:
>> Il 08/01/2014 04:07, Peter Crosthwaite ha scritto:
>>>>> The crash is because of commit 7426aa7 (nand: Don't inherit from Sysbus,
>>>>> 2013-06-18). Should probably be reverted.
>>>>>
>>> Prefer not, under no reasonable definition is NAND a sysbus device.
>>> Whats the real problem here? What is TYPE_SYS_BUS_DEVICE doing WRT to
>>> qtree that TYPE_DEVICE is not?
>>
>> The device's dev->parent_bus is main_system_bus.
>
> Meaning in turn that qdev_create() was used rather then object_new().
> Simple fix. :)
Happy as usual to be shown wrong! :)
> Possibly already in my pending qom-next pull?
No, unfortunately not.
Paolo
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 14:04 ` Paolo Bonzini
@ 2014-01-08 14:35 ` Markus Armbruster
2014-01-08 15:18 ` Paolo Bonzini
0 siblings, 1 reply; 26+ messages in thread
From: Markus Armbruster @ 2014-01-08 14:35 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Peter Crosthwaite, Alexander Graf, Anthony Liguori,
QEMU Developers
Paolo Bonzini <pbonzini@redhat.com> writes:
> Leaving only those that will be affected by the patch:
You omitted akita, borzoi, connex, mainstone, nuri, smdkc210, spitz,
terrier, tosa, verdex, z2, s390-virtio. Why won't they be affected?
You also omitted the machines that I can't get to start, but I'm not
overly worried by them, because they're all either Xen, where I don't
expect differences to plain x86, or ppcemb, where Alex gets to clean up
any mess he might make.
> Il 07/01/2014 18:34, Markus Armbruster ha scritto:
>> 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 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
>
> With Alex's patch we get the ability to plug the device in a particular
> slot. If anyone was using virtio-mmio-bus.0 explicitly, they get the
> first slot instead of the 4th or 32nd. Bugfix.
Doesn't this break migration? If yes, do we care?
>> aarch64 xilinx-zynq-a9 usb-bus.0 2
>> arm xilinx-zynq-a9 usb-bus.0 2
>> mips64el fulong2e usb-bus.0 2
>
> With Alex's patch we get the ability to plug the device in a particular
> controller. If anyone was using usb-bus.0 explicitly, they get the
> "other" controller. Guest visible change and not really a bugfix but it
> doesn't break working configurations (the position of USB devices should
> not be part of a device tree or firmware blob). It may break migration.
>
>> i386 isapc ide.0 2
>> x86_64 isapc ide.0 2
>
> (Ugly) fix in Alex's patch. The macio approach (using QOM children) is
> better. No need for a perfect fix now.
I'm fine with Alex's ugly fix.
>> mips mips ide.0 2
>> mips64 mips ide.0 2
>> mips64el mips ide.0 2
>> mipsel mips ide.0 2
>
> Not affected, the bus is not stored anywhere.
Isn't command line use and migration affected, just like everywhere
else?
>> 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
>
> Trusting Alex's tests here.
Our analysis should be recorded in the commit message. With that done,
I could R-by the patch.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 14:35 ` Markus Armbruster
@ 2014-01-08 15:18 ` Paolo Bonzini
2014-01-08 16:52 ` Markus Armbruster
0 siblings, 1 reply; 26+ messages in thread
From: Paolo Bonzini @ 2014-01-08 15:18 UTC (permalink / raw)
To: Markus Armbruster
Cc: Peter Crosthwaite, Alexander Graf, Anthony Liguori,
QEMU Developers
Il 08/01/2014 15:35, Markus Armbruster ha scritto:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
>> Leaving only those that will be affected by the patch:
>
> You omitted akita, borzoi, connex, mainstone, nuri, smdkc210, spitz,
> terrier, tosa, verdex, z2, s390-virtio. Why won't they be affected?
Because the dup bus names are hardcoded in the board:
i2cbus = i2c_init_bus(dev, "dummy");
or in the device:
s->spi = g_new(SSIBus *, s->num_busses);
for (i = 0; i < s->num_busses; ++i) {
char bus_name[16];
snprintf(bus_name, 16, "spi%d", i);
s->spi[i] = ssi_create_bus(dev, bus_name);
}
Only dups of the "xyzzy.NN" form have their bus names created by qdev
core. For other buses this patch changes nothing (neither for better,
nor for worse).
> You also omitted the machines that I can't get to start, but I'm not
> overly worried by them, because they're all either Xen, where I don't
> expect differences to plain x86, or ppcemb, where Alex gets to clean up
> any mess he might make.
Right. In particular xenfv is just a PIIX PC, plus the (non qdev) Xen
PV bus. And xenpv is just the Xen PV bus.
>> Il 07/01/2014 18:34, Markus Armbruster ha scritto:
>>> 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 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
>>
>> With Alex's patch we get the ability to plug the device in a particular
>> slot. If anyone was using virtio-mmio-bus.0 explicitly, they get the
>> first slot instead of the 4th or 32nd. Bugfix.
>
> Doesn't this break migration? If yes, do we care?
I don't know for sure, but probably not. sysbus doesn't implement
get_dev_path, so it relies on the old instance_id mechanism to
distinguish devices. instance_id is unreliable in general (e.g. with
hotplug), but for command-lines and no hot-plug/hot-unplug it should
work. You do have to be careful and specify bus=virtio-mmio-bus.31 on
the destination if you used bus=virtio-mmio-bus.0 on the source.
BTW if you didn't use bus=virtio-mmio-bus.0, nothing changes because the
logic in qbus_find_recursive is unaffected.
>>> mips mips ide.0 2
>>> mips64 mips ide.0 2
>>> mips64el mips ide.0 2
>>> mipsel mips ide.0 2
>>
>> Not affected, the bus is not stored anywhere.
>
> Isn't command line use and migration affected, just like everywhere
> else?
Right, command-line use of ide.0. Bugfix as in Alex's PPC case, because
makes everything else consistent with PCI IDE which is the only place
where bus=ide.N worked.
Migration is not affected unless you used ide.0 on the command line. In
other words, migration from old "-drive if=ide,bus=N" to new "-drive
if=none ... -device ...,bus=ide.N" should work.
>>> 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
>>
>> Trusting Alex's tests here.
>
> Our analysis should be recorded in the commit message. With that done,
> I could R-by the patch.
Alex, can you spin v3 with a new commit message?
Paolo
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 15:18 ` Paolo Bonzini
@ 2014-01-08 16:52 ` Markus Armbruster
0 siblings, 0 replies; 26+ messages in thread
From: Markus Armbruster @ 2014-01-08 16:52 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Peter Crosthwaite, Alexander Graf, Anthony Liguori,
QEMU Developers
Paolo Bonzini <pbonzini@redhat.com> writes:
> Il 08/01/2014 15:35, Markus Armbruster ha scritto:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>
>>> Leaving only those that will be affected by the patch:
>>
>> You omitted akita, borzoi, connex, mainstone, nuri, smdkc210, spitz,
>> terrier, tosa, verdex, z2, s390-virtio. Why won't they be affected?
>
> Because the dup bus names are hardcoded in the board:
>
> i2cbus = i2c_init_bus(dev, "dummy");
>
> or in the device:
>
> s->spi = g_new(SSIBus *, s->num_busses);
> for (i = 0; i < s->num_busses; ++i) {
> char bus_name[16];
> snprintf(bus_name, 16, "spi%d", i);
> s->spi[i] = ssi_create_bus(dev, bus_name);
> }
>
> Only dups of the "xyzzy.NN" form have their bus names created by qdev
> core. For other buses this patch changes nothing (neither for better,
> nor for worse).
Ah, right.
These duplicates are just as wrong. But demanding everything gets fixed
usually gets us nothing fixed, so I'm not going to do that.
>> You also omitted the machines that I can't get to start, but I'm not
>> overly worried by them, because they're all either Xen, where I don't
>> expect differences to plain x86, or ppcemb, where Alex gets to clean up
>> any mess he might make.
>
> Right. In particular xenfv is just a PIIX PC, plus the (non qdev) Xen
> PV bus. And xenpv is just the Xen PV bus.
>
>>> Il 07/01/2014 18:34, Markus Armbruster ha scritto:
>>>> 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 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
>>>
>>> With Alex's patch we get the ability to plug the device in a particular
>>> slot. If anyone was using virtio-mmio-bus.0 explicitly, they get the
>>> first slot instead of the 4th or 32nd. Bugfix.
>>
>> Doesn't this break migration? If yes, do we care?
>
> I don't know for sure, but probably not. sysbus doesn't implement
> get_dev_path, so it relies on the old instance_id mechanism to
> distinguish devices. instance_id is unreliable in general (e.g. with
> hotplug), but for command-lines and no hot-plug/hot-unplug it should
> work. You do have to be careful and specify bus=virtio-mmio-bus.31 on
> the destination if you used bus=virtio-mmio-bus.0 on the source.
That's enough breakage to require documenting the issue in the commit
message, and possibly release notes. Can be done as part of a single
list of affected machines and buses, with a general note on how the
interpretation of bus=FOO.0 changes, how that can affect migration, and
a hint on possible work-arounds.
> BTW if you didn't use bus=virtio-mmio-bus.0, nothing changes because the
> logic in qbus_find_recursive is unaffected.
>
>>>> mips mips ide.0 2
>>>> mips64 mips ide.0 2
>>>> mips64el mips ide.0 2
>>>> mipsel mips ide.0 2
>>>
>>> Not affected, the bus is not stored anywhere.
>>
>> Isn't command line use and migration affected, just like everywhere
>> else?
>
> Right, command-line use of ide.0. Bugfix as in Alex's PPC case, because
> makes everything else consistent with PCI IDE which is the only place
> where bus=ide.N worked.
>
> Migration is not affected unless you used ide.0 on the command line. In
> other words, migration from old "-drive if=ide,bus=N" to new "-drive
> if=none ... -device ...,bus=ide.N" should work.
>
>>>> 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
>>>
>>> Trusting Alex's tests here.
>>
>> Our analysis should be recorded in the commit message. With that done,
>> I could R-by the patch.
>
> Alex, can you spin v3 with a new commit message?
Yes, please.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-08 13:47 ` Paolo Bonzini
@ 2014-01-10 7:50 ` Peter Crosthwaite
2014-01-10 8:48 ` Markus Armbruster
0 siblings, 1 reply; 26+ messages in thread
From: Peter Crosthwaite @ 2014-01-10 7:50 UTC (permalink / raw)
To: Paolo Bonzini
Cc: QEMU Developers, Markus Armbruster, Andreas Färber,
Anthony Liguori, Alexander Graf
On Wed, Jan 8, 2014 at 11:47 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 08/01/2014 14:40, Andreas Färber ha scritto:
>> > Either you fix "info qtree" to cope with your change to the device
>> > graph, or the change needs to be reverted until somebody fixes it or it
>> > goes away.
>> Sharing a backtrace would be a start, rather than just throwing around
>> the word "crash" to justify reverting patches. :)
>
> I mentioned the root cause in the previous message: a Device cannot be
> added to main_system_bus, but that's what the patch does. The fix isn't
> trivial, because most of the affected board are not even qdevified.
>
So I made progress here with the needed QOMification. Finally I have a
sane info qtree WRT NAND:
$ arm-softmmu/qemu-system-arm -M spitz -nographic -S
(qemu) info qtree
bus: main-system-bus
type System
...
dev: sl-nand, id ""
manf_id = 236
chip_id = 115
irq 0
mmio 000000000c000000/0000000000000040
bus: nand
type nand-bus
dev: nand, id ""
manufacturer_id = 236
chip_id = 115
drive = <null>
With just the proposed revert info qtree does work again, but is bogus:
(qemu) info qtree
bus: main-system-bus
type System
...
dev: nand, id ""
manufacturer_id = 236
chip_id = 115
drive = <null>
irq 0
dev: sl-nand, id ""
manf_id = 236
chip_id = 115
irq 0
mmio 000000000c000000/0000000000000040
Patches sometime next week hopefully.
Regards,
Peter
> Paolo
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-10 7:50 ` Peter Crosthwaite
@ 2014-01-10 8:48 ` Markus Armbruster
2014-02-04 9:28 ` Markus Armbruster
0 siblings, 1 reply; 26+ messages in thread
From: Markus Armbruster @ 2014-01-10 8:48 UTC (permalink / raw)
To: Peter Crosthwaite
Cc: Paolo Bonzini, Alexander Graf, QEMU Developers, Anthony Liguori,
Andreas Färber
Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:
> On Wed, Jan 8, 2014 at 11:47 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 08/01/2014 14:40, Andreas Färber ha scritto:
>>> > Either you fix "info qtree" to cope with your change to the device
>>> > graph, or the change needs to be reverted until somebody fixes it or it
>>> > goes away.
>>> Sharing a backtrace would be a start, rather than just throwing around
>>> the word "crash" to justify reverting patches. :)
>>
>> I mentioned the root cause in the previous message: a Device cannot be
>> added to main_system_bus, but that's what the patch does. The fix isn't
>> trivial, because most of the affected board are not even qdevified.
>>
>
> So I made progress here with the needed QOMification. Finally I have a
> sane info qtree WRT NAND:
>
> $ arm-softmmu/qemu-system-arm -M spitz -nographic -S
> (qemu) info qtree
> bus: main-system-bus
> type System
> ...
> dev: sl-nand, id ""
> manf_id = 236
> chip_id = 115
> irq 0
> mmio 000000000c000000/0000000000000040
> bus: nand
> type nand-bus
> dev: nand, id ""
> manufacturer_id = 236
> chip_id = 115
> drive = <null>
>
> With just the proposed revert info qtree does work again, but is bogus:
>
> (qemu) info qtree
> bus: main-system-bus
> type System
> ...
> dev: nand, id ""
> manufacturer_id = 236
> chip_id = 115
> drive = <null>
> irq 0
> dev: sl-nand, id ""
> manf_id = 236
> chip_id = 115
> irq 0
> mmio 000000000c000000/0000000000000040
Progress!
> Patches sometime next week hopefully.
I think we can wait that long :)
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-01-10 8:48 ` Markus Armbruster
@ 2014-02-04 9:28 ` Markus Armbruster
2014-02-05 5:19 ` Peter Crosthwaite
0 siblings, 1 reply; 26+ messages in thread
From: Markus Armbruster @ 2014-02-04 9:28 UTC (permalink / raw)
To: Peter Crosthwaite
Cc: Paolo Bonzini, Alexander Graf, QEMU Developers, Anthony Liguori,
Andreas Färber
Markus Armbruster <armbru@redhat.com> writes:
> Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:
>
>> On Wed, Jan 8, 2014 at 11:47 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> Il 08/01/2014 14:40, Andreas Färber ha scritto:
>>>> > Either you fix "info qtree" to cope with your change to the device
>>>> > graph, or the change needs to be reverted until somebody fixes it or it
>>>> > goes away.
>>>> Sharing a backtrace would be a start, rather than just throwing around
>>>> the word "crash" to justify reverting patches. :)
>>>
>>> I mentioned the root cause in the previous message: a Device cannot be
>>> added to main_system_bus, but that's what the patch does. The fix isn't
>>> trivial, because most of the affected board are not even qdevified.
>>>
>>
>> So I made progress here with the needed QOMification. Finally I have a
>> sane info qtree WRT NAND:
>>
>> $ arm-softmmu/qemu-system-arm -M spitz -nographic -S
>> (qemu) info qtree
>> bus: main-system-bus
>> type System
>> ...
>> dev: sl-nand, id ""
>> manf_id = 236
>> chip_id = 115
>> irq 0
>> mmio 000000000c000000/0000000000000040
>> bus: nand
>> type nand-bus
>> dev: nand, id ""
>> manufacturer_id = 236
>> chip_id = 115
>> drive = <null>
>>
>> With just the proposed revert info qtree does work again, but is bogus:
>>
>> (qemu) info qtree
>> bus: main-system-bus
>> type System
>> ...
>> dev: nand, id ""
>> manufacturer_id = 236
>> chip_id = 115
>> drive = <null>
>> irq 0
>> dev: sl-nand, id ""
>> manf_id = 236
>> chip_id = 115
>> irq 0
>> mmio 000000000c000000/0000000000000040
>
> Progress!
>
>> Patches sometime next week hopefully.
>
> I think we can wait that long :)
I just ran into the info qtree crash again, and I can't find your fix
right now. Got a pointer for me?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-02-04 9:28 ` Markus Armbruster
@ 2014-02-05 5:19 ` Peter Crosthwaite
2014-02-05 8:45 ` Markus Armbruster
0 siblings, 1 reply; 26+ messages in thread
From: Peter Crosthwaite @ 2014-02-05 5:19 UTC (permalink / raw)
To: Markus Armbruster
Cc: Paolo Bonzini, Andreas Färber, Alexander Graf,
Anthony Liguori, QEMU Developers
On Tue, Feb 4, 2014 at 7:28 PM, Markus Armbruster <armbru@redhat.com> wrote:
> Markus Armbruster <armbru@redhat.com> writes:
>
>> Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:
>>
>>> On Wed, Jan 8, 2014 at 11:47 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>> Il 08/01/2014 14:40, Andreas Färber ha scritto:
>>>>> > Either you fix "info qtree" to cope with your change to the device
>>>>> > graph, or the change needs to be reverted until somebody fixes it or it
>>>>> > goes away.
>>>>> Sharing a backtrace would be a start, rather than just throwing around
>>>>> the word "crash" to justify reverting patches. :)
>>>>
>>>> I mentioned the root cause in the previous message: a Device cannot be
>>>> added to main_system_bus, but that's what the patch does. The fix isn't
>>>> trivial, because most of the affected board are not even qdevified.
>>>>
>>>
>>> So I made progress here with the needed QOMification. Finally I have a
>>> sane info qtree WRT NAND:
>>>
>>> $ arm-softmmu/qemu-system-arm -M spitz -nographic -S
>>> (qemu) info qtree
>>> bus: main-system-bus
>>> type System
>>> ...
>>> dev: sl-nand, id ""
>>> manf_id = 236
>>> chip_id = 115
>>> irq 0
>>> mmio 000000000c000000/0000000000000040
>>> bus: nand
>>> type nand-bus
>>> dev: nand, id ""
>>> manufacturer_id = 236
>>> chip_id = 115
>>> drive = <null>
>>>
>>> With just the proposed revert info qtree does work again, but is bogus:
>>>
>>> (qemu) info qtree
>>> bus: main-system-bus
>>> type System
>>> ...
>>> dev: nand, id ""
>>> manufacturer_id = 236
>>> chip_id = 115
>>> drive = <null>
>>> irq 0
>>> dev: sl-nand, id ""
>>> manf_id = 236
>>> chip_id = 115
>>> irq 0
>>> mmio 000000000c000000/0000000000000040
>>
>> Progress!
>>
>>> Patches sometime next week hopefully.
>>
>> I think we can wait that long :)
>
> I just ran into the info qtree crash again, and I can't find your fix
> right now. Got a pointer for me?
>
Hi Markus,
That series got very big on me with complications. I think near term
we just proceed with the revert. Sorry for the delay.
For a straight revert of my patch nand s/SYSBUS/DEVICE patch:
Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Regards,
Peter
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus
2014-02-05 5:19 ` Peter Crosthwaite
@ 2014-02-05 8:45 ` Markus Armbruster
0 siblings, 0 replies; 26+ messages in thread
From: Markus Armbruster @ 2014-02-05 8:45 UTC (permalink / raw)
To: Peter Crosthwaite
Cc: QEMU Developers, Paolo Bonzini, Andreas Färber,
Anthony Liguori, Alexander Graf
Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:
> On Tue, Feb 4, 2014 at 7:28 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> Markus Armbruster <armbru@redhat.com> writes:
>>
>>> Peter Crosthwaite <peter.crosthwaite@xilinx.com> writes:
>>>
>>>> On Wed, Jan 8, 2014 at 11:47 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>>>> Il 08/01/2014 14:40, Andreas Färber ha scritto:
>>>>>> > Either you fix "info qtree" to cope with your change to the device
>>>>>> > graph, or the change needs to be reverted until somebody fixes it or it
>>>>>> > goes away.
>>>>>> Sharing a backtrace would be a start, rather than just throwing around
>>>>>> the word "crash" to justify reverting patches. :)
>>>>>
>>>>> I mentioned the root cause in the previous message: a Device cannot be
>>>>> added to main_system_bus, but that's what the patch does. The fix isn't
>>>>> trivial, because most of the affected board are not even qdevified.
>>>>>
>>>>
>>>> So I made progress here with the needed QOMification. Finally I have a
>>>> sane info qtree WRT NAND:
>>>>
>>>> $ arm-softmmu/qemu-system-arm -M spitz -nographic -S
>>>> (qemu) info qtree
>>>> bus: main-system-bus
>>>> type System
>>>> ...
>>>> dev: sl-nand, id ""
>>>> manf_id = 236
>>>> chip_id = 115
>>>> irq 0
>>>> mmio 000000000c000000/0000000000000040
>>>> bus: nand
>>>> type nand-bus
>>>> dev: nand, id ""
>>>> manufacturer_id = 236
>>>> chip_id = 115
>>>> drive = <null>
>>>>
>>>> With just the proposed revert info qtree does work again, but is bogus:
>>>>
>>>> (qemu) info qtree
>>>> bus: main-system-bus
>>>> type System
>>>> ...
>>>> dev: nand, id ""
>>>> manufacturer_id = 236
>>>> chip_id = 115
>>>> drive = <null>
>>>> irq 0
>>>> dev: sl-nand, id ""
>>>> manf_id = 236
>>>> chip_id = 115
>>>> irq 0
>>>> mmio 000000000c000000/0000000000000040
>>>
>>> Progress!
>>>
>>>> Patches sometime next week hopefully.
>>>
>>> I think we can wait that long :)
>>
>> I just ran into the info qtree crash again, and I can't find your fix
>> right now. Got a pointer for me?
>>
>
> Hi Markus,
>
> That series got very big on me with complications. I think near term
> we just proceed with the revert. Sorry for the delay.
>
> For a straight revert of my patch nand s/SYSBUS/DEVICE patch:
>
> Acked-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Done. Thanks!
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2014-02-05 8:45 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-20 1:41 [Qemu-devel] [PATCH v2] qdev: Keep global allocation counter per bus Alexander Graf
2013-12-21 10:42 ` Markus Armbruster
2013-12-22 13:43 ` Paolo Bonzini
2014-01-07 15:12 ` Markus Armbruster
2014-01-07 16:59 ` Paolo Bonzini
2014-01-07 17:34 ` Markus Armbruster
2014-01-08 14:04 ` Paolo Bonzini
2014-01-08 14:35 ` Markus Armbruster
2014-01-08 15:18 ` Paolo Bonzini
2014-01-08 16:52 ` Markus Armbruster
2014-01-08 3:07 ` Peter Crosthwaite
2014-01-08 4:24 ` Andreas Färber
2014-01-08 8:00 ` Markus Armbruster
2014-01-08 10:11 ` Peter Maydell
2014-01-08 8:13 ` Markus Armbruster
2014-01-08 8:26 ` Peter Crosthwaite
2014-01-08 13:40 ` Andreas Färber
2014-01-08 13:47 ` Paolo Bonzini
2014-01-10 7:50 ` Peter Crosthwaite
2014-01-10 8:48 ` Markus Armbruster
2014-02-04 9:28 ` Markus Armbruster
2014-02-05 5:19 ` Peter Crosthwaite
2014-02-05 8:45 ` Markus Armbruster
2014-01-08 11:02 ` Paolo Bonzini
2014-01-08 13:53 ` Andreas Färber
2014-01-08 14:07 ` Paolo Bonzini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).