qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/6] kvm: Rename kvm_irqchip_set_irq to kvm_inje


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 2/6] kvm: Rename kvm_irqchip_set_irq to kvm_inject_async_irq
Date: Wed, 25 Jul 2012 17:18:25 +0100

On 25 July 2012 17:11, Jan Kiszka <address@hidden> wrote:
> On 2012-07-25 18:09, Peter Maydell wrote:
>> On 25 July 2012 16:58, Jan Kiszka <address@hidden> wrote:
>>> Hmm, what was question again? Ah: Do we have an arch that implements it
>>> without providing a (logical) irqchip? At least at this time (including
>>> ARM)?
>>
>> Well, it depends what you mean by 'irqchip' (part of the point of
>> this series being that there isn't a coherent architecture
>> independent definition of that and so we shouldn't use the term
>> in architecture-independent code).
>> On ARM we will use KVM_IRQ_LINE whether we have an in-kernel VGIC
>> or not, because we always use async interrupt injection.
>>
>> (That is, the same arguments for "why should this function be
>> guarded by kvm_async_interrupt_injection() rather than
>> kvm_irqchip_in_kernel()?" apply to "why should this function not
>> have 'irqchip' in the function name.)
>
> Wasn't Avi's point that you do have an irqchip in your KVM support?

Not in the sense of "you need to KVM_CREATE_IRQCHIP it",
or in the sense of "this might be a useful thing to expose
to the user as a togglable option", which are the main
interesting architecture-independent bits of kernel_irqchip=on.

IIRC Alex said that PPC has a similar setup -- interrupts are
always sent asynchronously whether you've created the kernel
irqchip or not.

In any case I think it's much clearer to actually name things
based on what they're really testing for rather than things
that might or might not be correlated with that, even in
the (hypothetical) case that all architectures had an irqchip
if and only if they did async interrupt delivery.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]