qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] kvm-all.c: Move init of irqchip_inject_ioctl ou


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH] kvm-all.c: Move init of irqchip_inject_ioctl out of kvm_irqchip_create()
Date: Tue, 14 Aug 2012 15:36: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-08-14 15:14, Avi Kivity wrote:
> On 08/14/2012 02:05 PM, Jan Kiszka wrote:
>> On 2012-08-14 13:01, Avi Kivity wrote:
>>> On 08/14/2012 10:33 AM, Jan Kiszka wrote:
>>>>
>>>> KVM_IRQ_LINE is old-style, deprecated, KVM_IRQ_LINE_STATUS (i.e
>>>> injection with feedback to allow lost-tick compensation) is the current
>>>> standard that other archs should pick up.
>>>
>>> KVM_IRQ_LINE_STATUS may not make sense on all architectures.
>>>
>>> I don't think we're really deprecating KVM_IRQ_LINE or discouraging its
>>> use.  It's not like the kernel-allocated memory slot ioctls.
>>
>> I do not think it makes sense to provide both interfaces long term
>> (provided we ever do a cut). Also, it's almost trivial to provide the
>> add-on feature of KVM_IRQ_LINE_STATUS, and it keeps the door open for
>> IRQ decoalescing. If there is no way for an arch to detect coalescing,
>> it can still return >0 unconditionally.
> 
> That's lying.  I don't see how anything bad can come out of it, but we
> can always be surprised.  If we can't support something, let's not claim
> we do.

Fortunately, we are not in this position on ARM. It has in in-kernel
irqchip and can tell if some line is still being processed.

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]