Re: [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386

[Avi Kivity <avi@redhat.com>]

On 07/23/2012 04:27 PM, Peter Maydell wrote:
> On 23 July 2012 14:09, Avi Kivity <avi@redhat.com> 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