[Top][All Lists]

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

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

From: Alexander Graf
Subject: Re: [Qemu-devel] passing interrupts from QEMU to KVM
Date: Thu, 19 Jul 2012 16:13:00 +0200
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 07/19/2012 02:00 PM, Peter Maydell wrote:
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 latter is how PPC works today. We have an EXT IRQ line on the CPU which gets pulled up or lowered by the piece of code you were wondering about. It's different from x86's model, which wants to know synchronously when to inject an interrupt. We are fully asynchronous, but only provide a single line to control.

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 :-))

Heh. I would really like to keep the !in_kernel_irqchip path (so only an EXT IRQ line exposed) available for PPC at least. It has helped tremendously in the past to be able to just throw a few debug printfs into QEMU and/or compare with TCG what's happening when things go wrong.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]