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: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 2/6] kvm: Rename kvm_irqchip_set_irq to kvm_inject_async_irq
Date: Wed, 25 Jul 2012 18:11:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-07-25 18:09, Peter Maydell wrote:
> On 25 July 2012 16:58, Jan Kiszka <address@hidden> wrote:
>> On 2012-07-25 17:56, Peter Maydell wrote:
>>> On 25 July 2012 16:55, Avi Kivity <address@hidden> wrote:
>>>> On 07/25/2012 06:53 PM, Jan Kiszka wrote:
>>>>> We don't have a synchronous function anymore, it's part of the pre-run
>>>>> code of x86 IIRC.
>>>>
>>>> Right.  There's a DPRINTF() there that talks about injection, too.  So I
>>>> think this patch can be dropped.
>>>
>>> The main purpose of the patch is to remove 'irqchip' from the
>>> function name, because the function isn't restricted to use
>>> with in-kernel irqchips.
>>
>> 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?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux





reply via email to

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