qemu-devel
[Top][All Lists]
Advanced

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

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [RFC PATCH v3 01/10] hw: arm_gic: Fix gic_set_irq handling
Date: Thu, 19 Dec 2013 09:03:51 +0000

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].

thanks
-- PMM



reply via email to

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