Re: [Qemu-devel] [RFC PATCH v3 01/10] hw: arm_gic: Fix gic_set_irq handling

[Peter Crosthwaite]

On Thu, Dec 19, 2013 at 7:03 PM, Peter Maydell <address@hidden> wrote:
> On 19 December 2013 05:49, Christoffer Dall <address@hidden> wrote:
>> On Thu, Nov 28, 2013 at 05:43:54PM +0000, Peter Maydell wrote:
>>> The other possibility is that it's a correct implementation
>>> of 11MPCore GIC semantics -- the documentation of the
>>> 11MPCore definitely says that level triggered interrupts
>>> go from Pending to Active and can't be Active+Pending
>>> unless software messes with the GIC state. So either
>>> the docs are actively wrong for 11MPCore or it behaves
>>> differently from GICv1 and v2 here (my guess would be
>>> the latter, in which case we need to support both flavours).
>>>
>> A correct implementation?  I don't see how, unless the pending/level
>> fields are used in some obscure different way for the 11MPCore than for
>> GICv2.0.
>
> That is my point -- the 11MPCore docs say that pending works
> differently.
>
>> That being said, we are absolutely sure that support the 11MPCore is
>> still needed?
>
> I can't just rip it all out of QEMU, really, though it does count
> as one of our less used CPUs I suspect.
>
>> I would probably go the route of creating some structs with function
>> pointers in them for things like the ack or raise etc. which have
>> different semantics for the two versions and have separate functions to
>> reduce the branching in each funciton.  What do you think?
>
> My initial thought would be either to have if statements at the
> relevant points (which is how we've handled 11mpcore
> differences so far), or to bite the bullet and reflect the
> difference in the QOM class structure so we can use
> QOM methods [ie function pointers in the class struct].
>

Even in the "if" approach its probably best to put the "is-11mpcore"
or "version" property in the class structure. So I think you want the
QOM class structure both ways.

Regards,
Peter

> thanks
> -- PMM
>