[Top][All Lists]

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

[Qemu-devel] passing interrupts from QEMU to KVM

From: Peter Maydell
Subject: [Qemu-devel] passing interrupts from QEMU to KVM
Date: Thu, 19 Jul 2012 12:14:59 +0100

Hi; I'm a bit confused about handling of passing interrupts
to KVM from QEMU.

Looking at a few of the current platforms:

x86, no in-kernel irqchip:
 * we seem to use the usual non-KVM cpu_interrupt() and
   cpu_reset_interrupt() functions, which in a KVM enabled QEMU
   set flags in env->interrupt_request and do a qemu_cpu_kick().
   Then later on we might try to inject an interrupt based on
   env->interrupt_request as part of the code in kvm_arch_pre_run.

x86, in kernel irqchip:
 * I think that the hw/kvm/ devices call kvm_irqchip_set_irq(),
   which just does a kvm_vm_ioctl() to insert an interrupt.
   This seems straightforward enough.

 * hw/ppc calls cpu_interrupt()/cpu_reset_interrupt(), but if
   KVM is enabled it *also* calls kvmppc_set_interrupt(), which
   does a kvm_vcpu_ioctl. It's not clear to me why we have to
   do both here.

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...

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?

-- PMM

reply via email to

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