On 03/31/2014 03:25 PM, Marc Zyngier wrote:
On 31/03/14 14:07, Peter Maydell wrote:
On 13 March 2014 15:57, Antonios Motakis
<a.motakis@xxxxxxxxxxxxxxxxxxxxxx> wrote:
(3) Implement routing support for the VGIC and using the VGIC via irqchip.c.
Assuming support for a GIC with Cortex-A15 CPUs, we can refer to the A15 TRM
Don't assume A15, please. The API should be based on the GIC
architectural specifications, not on a particular implementation
(especially when we already have multiple implementations
supported!) Notice that the IRQ_LINE API that you quote does
this -- we leave at least enough space for the architectural
maximums, not merely the A15's maximums.
Indeed. I already have patches to make the number of interrupts a
runtime configuration option (see the kvm-arm64/vgic-dyn branch in my repo).
Also, in the light of what is coming with GICv3, I don't want the limit
of 8 vcpus to propagate too far beyond the GICv2 emulation code.
It would also be helpful if you could explain what the
IRQ routing API you're proposing is -- the KVM api.txt
is extremely x86 specific in this area and it's not
clear to me what "IRQ routing" means for ARM...
Agreed. As much as I'd like to use as much of the common KVM API as
possible, I want to see how this is going to map with the architecture
(knowing that the whole interrupt subsystem is undergoing a massive
rework with GICv3/4, MSI and co).
IRQ Routing is really just a map from a flat number space that KVM uses
internally to specific interrupt controller pins. So if you see a "GSI"
that really just means "global interrupt index number".
During my PPC in-kernel IRQ routing cleanup I made sure there's no x86
cruft in the common code left, so you should be pretty safe.
Alex
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
