On 01/15/2013 04:17 PM, Gleb Natapov wrote: > On Tue, Jan 15, 2013 at 02:04:47PM +0000, Peter Maydell wrote: >> On 15 January 2013 12:52, Gleb Natapov<gleb@xxxxxxxxxx> wrote: >>> On Tue, Jan 15, 2013 at 12:15:01PM +0000, Peter Maydell wrote: >>>> On 15 January 2013 09:56, Gleb Natapov<gleb@xxxxxxxxxx> wrote: >>>>>> ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip >>>>> CPU level interrupt should use KVM_INTERRUPT instead. >>>> No, that would be wrong. KVM_INTERRUPT is for interrupts which must be >>>> delivered synchronously to the CPU. KVM_IRQ_LINE is for interrupts which >>>> can be fed to the kernel asynchronously. It happens that on x86 "must be >>>> delivered synchronously" and "not going to in kernel irqchip" are the same, but >>>> this isn't true for other archs. For ARM all our interrupts can be fed >>>> to the kernel asynchronously, and so we use KVM_IRQ_LINE in all >>>> cases. >>> I do no quite understand what you mean by synchronously and >>> asynchronously. >> Synchronously: the vcpu has to be stopped and userspace then >> feeds in the interrupt to be taken when the guest is resumed. >> Asynchronously: any old thread can tell the kernel there's an >> interrupt, and the guest vcpu then deals with it when needed >> (the vcpu thread may leave the guest but doesn't come out of >> the host kernel to qemu). >> >>> The difference between KVM_INTERRUPT and KVM_IRQ_LINE line >>> is that former is used when destination cpu is known to userspace later >>> is used when kernel code is involved in figuring out the destination. >> This doesn't match up with Avi's explanation at all. >> >>> The >>> injections themselves are currently synchronous for both of them on x86 >>> and ARM. i.e vcpu is kicked out from guest mode when interrupt need to >>> be injected into a guest and vcpu state is changed to inject interrupt >>> during next guest entry. In the near feature x86 will be able to inject >>> interrupt without kicking vcpu out from the guest mode does ARM plan to >>> do the same? For GIC interrupts or for IRQ/FIQ or for both? >>> >>>> There was a big discussion thread about this on kvm and qemu-devel last >>>> July (and we cleaned up some of the QEMU code to not smoosh together >>>> all these different concepts under "do I have an irqchip or not?"). >>> Do you have a pointer? >> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02460.html >> and there was a later longer (but less clear) thread which included >> this mail from Avi: >> http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02872.html >> basically explaining that the reason for the weird synchronous >> KVM_INTERRUPT API is that it's emulating a weird synchronous >> hardware interface which is specific to x86. ARM doesn't have >> a synchronous interface in the same way, so it's much more >> straightforward to use KVM_IRQ_LINE. >> > OK. I see. So basically Avi saw KVM_INTERRUPT as an oddball interface > required only for APIC emulation in userspace. It is used for PIC also, > where this is not strictly needed, but this is for historical reasons > (KVM_IRQ_LINE was introduces late and it is GSI centric on x86). > > Thank you for the pointer. Yeah, please keep in mind that KVM_INTERRUPT is not a unified interface either. In fact, it is asynchronous on PPC :). And it's called KVM_S390_INTERRUPT on s390 and also asynchronous. X86 is the oddball here. But I don't care whether we call the ioctl to steer CPU interrupt pins KVM_INTERRUPT, KVM_S390_INTERRUPT or KVM_IRQ_LINE, as long as the code makes it obvious what is happening. Alex _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
