On Mon, 29 Oct 2012 14:25:21 +0800, haibin wang <wanghaibin202@xxxxxxxxx> wrote: > There is an idea just about the irq's numbers which the VGIC supports in > kvm. > > Look at this definition which is in arch/arm/include/adm/kvm_vgic.h file: > #define VGIC_NR_IRQS 128 > I think that is a bad definition. > > In my opinion, the VGIC should be used by various models, not just only > the vexpress model. Because the irq's numbers that the different models > support may be different, so I think this definition should be defined > the max number that A15 support (just like GIC which qemu simulated > in arm_gic_internal.h : It is a trade off between functionality and performance. Using massive arrays do not come for free (think of the impact on memory, cache...). Another aspect to consider is how many different interrupts you want to inject in your guest. Really. Not just from a theoretical point of view. I expect most guest to mostly use paravirtualized IO, and not try to model a real hardware platform. How many different interrupt sources do you expect? > /* Maximum number of possible interrupts, determined by the GIC > architecture */ > #define GIC_MAXIRQ 1020 > typedef struct gic_state { > ... > gic_irq_state irq_state[GIC_MAXIRQ]; > int irq_target[GIC_MAXIRQ]; > int priority1[GIC_INTERNAL][NCPU]; > ... > } gic_state; > ) > > However, I don't think it's a good idea as the above show. The better way > qemu notify irq number(different in different models)to kvm, just like the > way qemu notify gicd's or gicc's address to kvm. > > This is just my idea. Thanks. Do you mean having a dynamic allocation scheme? Sure, this is doable, though this is yet another ABI change, and we're trying to stop breaking it. I actually suspect the number of interrupts to be actually less than 128 (which gives you 96 SPIs). Please evaluate the cost of not having fixed-size arrays. Also, there's a dependency on the number of vcpus KVM allows per VM, which needs to be resolved one way or another. M. -- Fast, cheap, reliable. Pick two. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm