On 07/23/2012 04:27 PM, Peter Maydell wrote: > On 23 July 2012 14:09, Avi Kivity <avi@xxxxxxxxxx> wrote: >> On 07/23/2012 03:58 PM, Peter Maydell wrote: >>> 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". > > That seems reasonable, although we have an awkward ordering issue > in KVM as it stands: KVM_CREATE_IRQCHIP needs to be called before > we start creating VCPU threads (at the moment it is done via kvm_init) > but we don't know what kind of irqchip we want to create until the > machine model code actually creates the irqchip device, which generally > happens after the CPU object is created (and VCPU threads are created > at that point). We could fix that by moving creation of the actual > VCPU thread to vl.c after the model has been initialized. Seems to be purely a qemu problem, no? While I think it's reasonable to be flexible, in this case I think qemu ought to know all these things beforehand. > >>> 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? > > Well, strictly speaking the ARM<->GIC interface is implementation > defined, but in practice you can think of it as "the GIC controls > the IRQ and FIQ input lines to each core and uses them to signal > that an interrupt is present". There's no need for anything to > be signalled back in the other direction: the GIC will just continue > to hold IRQ asserted until the interrupt handler code writes the > relevant GIC register to indicate that the interrupt has been > handled. Okay. This agrees with my mental model of how it works. > (On a core with the virtualization extensions there are also > signals for the GIC to raise a virtual IRQ or FIQ, but we can > ignore those for KVM because we don't and can't provide the > virtualization extensions to a guest.) Yet. -- 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
