Re: [Qemu-devel] [PATCH 5/5] hw: arm_gic_kvm: Add KVM VGIC save/restore logic

[Christoffer Dall]

On Sat, Sep 21, 2013 at 06:38:19PM +0900, Peter Maydell wrote:
> On 21 September 2013 06:46, Christoffer Dall
> <address@hidden> wrote:
> > On Sat, Sep 21, 2013 at 06:22:23AM +0900, Peter Maydell wrote:
> >>  *) for getting TCG<->KVM and KVM-with-non-host-CPU cases
> >> right we need to do translation anyway, or at least think about it.
> >
> > Why? Wouldn't we always only support the case where QEMU emulates the
> > same model as KVM in the first case, and the kernel should behave the
> > same and export the same state if you ask for a specific target no
> > matter what the underlying hardware is, no?
> 
> If the kernel has to be able to do translation of the state, why
> not make its life easier by having it only need to do one thing
> (host h/w format -> whatever standard format we pick)
> rather than lots and lots of things
> (host CPU X h/w format -> format for supported guest CPU A,
>  host CPU X h/w format -> format for supported guest CPU B,
>  host CPU Y h/w format -> format for guest CPU A,
>  host CPU Y h/w format -> format for guest CPU B,
>  etc etc etc)
> 
> ? That's basically a cross product over every CPU we
> support.
> 
Good point.

So after reading the GIC specs again, the way I understand it is that
the APR regs have a bit set, if that group priority (a.k.a. preemption
level) has an active interrupt.  Further, multiple set bits would would
only happen if software acknowledges an interrupt and before EOIing it,
the GIC gets preempted by an interrupt with a higher group priority
(lower number).  Correct?

Further, and again, I don't think the spec is particularly clear on this
point, but I think it suggests that if bit[0] is set, then there's an
interrupt from interrupt priority group 0 (the group with the highest
priority) in the active state, if bit[1] is set, one from group 1 is
active, and so on.

That would be a perfectly fine format for the APR in the GICstate
structure, and the only remaining questions would be:

 (1) How many preemption levels should be supported, which would be most
     easily solved by just defining GICC_APR0-GICC_APR3 for all cpu
     interfaces.
 (2) How does the arm_gic_kvm.c code detect the underlying host CPU that
     the kernel read the register from when it returned the value of the
     register to do the proper translation?  I don't even want to think
     about how this will work on Big.Little...

-Christoffer