qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 2/3] object.c: object_class_dynamic_cast retu


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v1 2/3] object.c: object_class_dynamic_cast return NULL if the class has no type
Date: Mon, 17 Aug 2015 16:37:29 -0700

On Mon, Aug 17, 2015 at 3:33 PM, Andreas Färber <address@hidden> wrote:
> Am 18.08.2015 um 00:24 schrieb Alistair Francis:
>> On Sat, Aug 15, 2015 at 2:22 PM, Peter Crosthwaite
>> <address@hidden> wrote:
>>> On Mon, Jul 27, 2015 at 11:37 AM, Alistair Francis
>>> <address@hidden> wrote:
>>>> If the ObjectClass has no type return NULL instead of trying to compare
>>>> the type name.
>>>>
>>>
>>> What was the issue?
>>
>> There is a seg fault in object_class_dynamic_cast() because there is
>> no type in the ObjectClass struct.
>
> That should never happen, ever since TYPE_OBJECT is no longer NULL.
>
>> It happens when it is trying to cast the "pci-device", which is called
>> from the ahci_irq_lower() function. The function is testing if the
>> device is a pci device, so it should return NULL if it isn't valid.

Yes so I vaguely remember this now. It is about MSI interrupts which
have nothing to do with sysbus implementation. My solution was to rip
that PCI specific stuff out of AHCI completely in my branch. Should
sysbus and PCI AHCI classes install their own separate logic for this
part via a virtualised hook?

On the topic though, I notice many PCI devices have this MSI specific
logic in them. Is it possible for devs to just treat interrupts as
pins and the PCI layers do the MSI vs non-MSI logic switch in core
layers?

If Andreas' idea don't work this is still a core QOM bug though. I
think object_dynamic_cast should not have this segfault when passed a
non implementing object.

Regards,
Peter

>
> It rather sounds as if some build-time dependency is wrong, which we
> used to run into for the Container type before Paolo macrofied this.
>
> Please try again with a clean build - if it still occurs, we'll need a
> reproducible test case to investigate what is going on rather than
> papering over a latent bug.
>
> Thanks,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)



reply via email to

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