[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sysbus failed assert for xen_sysdev
From: |
Jason Andryuk |
Subject: |
Re: sysbus failed assert for xen_sysdev |
Date: |
Mon, 22 Jun 2020 23:40:55 -0400 |
On Mon, Jun 22, 2020 at 5:17 PM Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
>
> On 22/06/2020 21:33, Jason Andryuk wrote:
>
> > Hi,
> >
> > Running qemu devel for a Xen VM is failing an assert after the recent
> > "qdev: Rework how we plug into the parent bus" sysbus changes.
> >
> > qemu-system-i386: hw/core/qdev.c:102: qdev_set_parent_bus: Assertion
> > `dc->bus_type && object_dynamic_cast(OBJECT(bus), dc->bus_type)'
> > failed.
> >
> > dc->bus_type is "xen-sysbus" and it's the
> > `object_dynamic_cast(OBJECT(bus), dc->bus_type)` portion that fails
> > the assert. bus seems to be "main-system-bus", I think:
> > (gdb) p *bus
> > $3 = {obj = {class = 0x55555636d780, free = 0x7ffff7c40db0 <g_free>,
> > properties = 0x5555563f7180, ref = 3, parent = 0x5555563fe980}, parent
> > = 0x0, name = 0x5555563fec60 "main-system-bus", ...
> >
> > The call comes from hw/xen/xen-legacy-backend.c:706
> > sysbus_realize_and_unref(SYS_BUS_DEVICE(xen_sysdev), &error_fatal);
> >
> > Any pointers on what needs to be fixed?
>
> Hi Jason,
>
> My understanding is that the assert() is telling you that you're plugging a
> TYPE_SYS_BUS_DEVICE into a bus that isn't derived from TYPE_SYSTEM_BUS. A
> quick look
> at the file in question suggests that you could try changing the parent class
> of
> TYPE_XENSYSBUS from TYPE_BUS to TYPE_SYSTEM_BUS to see if that helps?
Hi, Mark.
Thanks, but unfortunately changing xensysbus_info .parent does not
stop the assert. But it kinda pointed me in the right direction.
xen-sysdev overrode the bus_type which was breaking sysbus_realize.
So drop that:
--- a/hw/xen/xen-legacy-backend.c
+++ b/hw/xen/xen-legacy-backend.c
@@ -824,7 +825,7 @@ static void xen_sysdev_class_init(ObjectClass
*klass, void *data)
DeviceClass *dc = DEVICE_CLASS(klass);
device_class_set_props(dc, xen_sysdev_properties);
- dc->bus_type = TYPE_XENSYSBUS;
+ //dc->bus_type = TYPE_XENSYSBUS;
}
static const TypeInfo xensysdev_info = {
Then I had a different instance of the failed assert trying to attach
xen-console-0 to xen-sysbus. So I made this change:
--- a/hw/xen/xen-legacy-backend.c
+++ b/hw/xen/xen-legacy-backend.c
@@ -789,6 +789,7 @@ static void xendev_class_init(ObjectClass *klass,
void *data)
set_bit(DEVICE_CATEGORY_MISC, dc->categories);
/* xen-backend devices can be plugged/unplugged dynamically */
dc->user_creatable = true;
+ dc->bus_type = TYPE_XENSYSBUS;
}
static const TypeInfo xendev_type_info = {
Then it gets farther... until
qemu-system-i386: hw/core/qdev.c:439: qdev_assert_realized_properly:
Assertion `dev->realized' failed.
dev->id is NULL. The failing device is:
(gdb) p *dev.parent_obj.class.type
$12 = {name = 0x555556207770 "cfi.pflash01",
Is that right?
I'm going to have to take a break from this now.
Regards,
Jason
- sysbus failed assert for xen_sysdev, Jason Andryuk, 2020/06/22
- Re: sysbus failed assert for xen_sysdev, Mark Cave-Ayland, 2020/06/22
- Re: sysbus failed assert for xen_sysdev,
Jason Andryuk <=
- Re: sysbus failed assert for xen_sysdev, Markus Armbruster, 2020/06/23
- RE: sysbus failed assert for xen_sysdev, Paul Durrant, 2020/06/23
- Re: sysbus failed assert for xen_sysdev, Jason Andryuk, 2020/06/23
- RE: sysbus failed assert for xen_sysdev, Paul Durrant, 2020/06/24
- Re: sysbus failed assert for xen_sysdev, Jason Andryuk, 2020/06/24
- RE: sysbus failed assert for xen_sysdev, Paul Durrant, 2020/06/24
- Re: sysbus failed assert for xen_sysdev, Jason Andryuk, 2020/06/23
- RE: sysbus failed assert for xen_sysdev, Paul Durrant, 2020/06/23
- Re: sysbus failed assert for xen_sysdev, Jason Andryuk, 2020/06/23