Re: An idea about irq numbers that the VGIC supports

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux