Re: [Qemu-devel] passing interrupts from QEMU to KVM

[Peter Maydell]

On 19 July 2012 12:43, Avi Kivity <address@hidden> 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