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
