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@xxxxxxx> >> Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx> >> --- >> 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? M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
