On 25/02/14 18:07, Will Deacon wrote:

On Wed, Feb 05, 2014 at 01:30:49PM +0000, Marc Zyngier wrote:

quoted

Introduce the support code for emulating a GICv2 on top of GICv3
hardware.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <redacted>
---
 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...