[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.
ppc:
* 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
- [Qemu-devel] passing interrupts from QEMU to KVM,
Peter Maydell <=