On 07/23/2012 03:58 PM, Peter Maydell wrote: > On 23 July 2012 13:26, Avi Kivity <avi@xxxxxxxxxx> wrote: >> Really, "irqchip in kernel" means asynchronous interrupts - you can >> inject an interrupt from outside the vcpu thread. Obviously if the vcpu >> is sleeping you need to wake it up and that pulls in idle management. >> >> "irqchip" for x86 really means the local APIC, which has a synchronous >> interface with the cpu core. "local APIC in kernel" really is >> equivalent to "kernel idle management", "KVM_IRQ_LINE", and irqfd. The >> ioapic and pit, on the other hand, don't contribute anything to this >> (just performance). > >> So yes, ARM with and without GIC are irqchip_in_kernel, since the >> ARM<->GIC interface is asynchronous. Whether to emulate the GIC or not >> is just a performance question. > > So should we be using something other than KVM_CREATE_IRQCHIP to > ask the kernel to create a GIC model for us (and leave KVM_CREATE_IRQCHIP > as a dummy "always succeed" ioctl)? Some time ago I suggested using the parameter to KVM_CREATE_IRQCHIP to select the "irqchip type". > >> So my view is that ARM with and without kernel GIC are >> irqchip_in_kernel, since whatever is the local APIC in ARM is always >> emulated in the kernel. > > I'm not sure ARM has any equivalent to the local APIC -- the GIC > deals with everything and we don't have any equivalent division > of labour to the x86 LAPIC-IOAPIC one. It's probably a tiny part of the core with no name. The point is that the x86<->lapic interface is synchronous and bidirectional, while the lapic<->ioapic interface is asynchronous (it is still bidirectional, but not in a stop-the-vcpu way). I assume the ARM<->GIC interface is unidirectional? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
