[PATCH 17/18] KVM: ARM: vgic: add the GICv3 backend

[Will Deacon]

On Wed, Feb 26, 2014 at 06:18:20PM +0000, Marc Zyngier wrote:
> On 25/02/14 18:07, Will Deacon wrote:
> > On Wed, Feb 05, 2014 at 01:30:49PM +0000, Marc Zyngier wrote:
> >> Introduce the support code for emulating a GICv2 on top of GICv3
> >> hardware.
> >>
> >> Acked-by: Catalin Marinas <catalin.marinas at arm.com>
> >> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
> >> ---
> >>  include/kvm/arm_vgic.h |  26 ++++++
> >>  virt/kvm/arm/vgic-v3.c | 220 +++++++++++++++++++++++++++++++++++++++++++++++++
> >>  virt/kvm/arm/vgic.c    |   2 +
> >>  3 files changed, 248 insertions(+)
> >>  create mode 100644 virt/kvm/arm/vgic-v3.c
> >>
> >> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> >> index c95039a..caeb8f4 100644
> >> --- a/include/kvm/arm_vgic.h
> >> +++ b/include/kvm/arm_vgic.h
> >> @@ -32,6 +32,7 @@
> >>  #define VGIC_NR_SHARED_IRQS	(VGIC_NR_IRQS - VGIC_NR_PRIVATE_IRQS)
> >>  #define VGIC_MAX_CPUS		KVM_MAX_VCPUS
> >>  #define VGIC_MAX_LRS		(1 << 6)
> >> +#define VGIC_V3_MAX_LRS		16
> > 
> > Since we have fewer list registers, doesn't the code in vgic.c need updating
> > to honour the relevant bounds? (e.g. the use of find_first_zero_bit in
> > vgic_queue_irq).
> 
> I'm confused. We've always used a variable, as even with GICv2, we
> usually have far less list registers than the maximum (4 vs 64). Looking
> at the code you mention, I see this:
> 
> 	/* Try to use another LR for this interrupt */
> 	lr = find_first_zero_bit((unsigned long *)vgic_cpu->lr_used,
> 			       vgic->nr_lr);
> 
> Am I looking at the wrong place?

No, I'm being stupid. I was looking at mainline rather than your GICv3
branch and thought we were still using VGIC_MAX_LRS.

Will