On 19 December 2013 05:49, Christoffer Dall <christoffer.dall@xxxxxxxxxx> 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
