On 19 July 2012 12:43, Avi Kivity <a...@redhat.com> wrote: > On 07/19/2012 02:14 PM, Peter Maydell wrote: >> >> Basically I'm not sure why there's all this variety here, >> or why x86 does things differently for in-kernel irqchip >> versus not -- I would have expected that the only difference >> for an in-kernel irqchip is that there are more interrupt >> lines. Kicking the CPU out of the kernel in particular seems >> a very roundabout way of telling it about an interrupt, >> but I assume there's a rationale for doing it that way... > > Non-in-kernel irqchip is synchronous; everything must be executed in > vcpu context. This is because the kernel does not queue any interrupts, > rather userspace requests an "interrupt window" (an instruction boundary > where the vcpu is ready for interrupt injection) and then qemu injects > that interrupt. > > In-kernel irqchip added the logic for queueing interrupts, and is > completely asynchronous. You can queue an interrupt from a different > thread, the kernel will inject it when the vcpu is ready.
Ah, right. So in that sense I think ARM currently has two different kinds of in-kernel-irqchip: the VGIC (has lots of interrupt lines, memory mapped registers for control, etc), and the not-VGIC (just two interrupt lines FIQ and IRQ). In either case there's no requirement for synchronous operation. >> The way I'm thinking about handling this for ARM is just >> to have both the irqchip and no-irqchip approaches be >> roughly the same: the device code just makes the relevant >> KVM ioctl to inject interrupts (the semantics of the irq >> number change for irqchip vs not irqchip but the general >> behaviour is the same), and we never call cpu_interrupt() >> if KVM is enabled. Is there any reason that wouldn't work? > Let's make them even more similar, by removing !in_kernel_irqchip. Mmm, I do rather want to just mandate use of the VGIC... (somebody will probably come along later and try to get A9 guests working with KVM acceleration but I don't think it will be me :-)) -- PMM
