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

[Avi Kivity <avi@redhat.com>]

On 07/23/2012 03:58 PM, Peter Maydell wrote:
> On 23 July 2012 13:26, Avi Kivity <avi@redhat.com> 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