From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] kvm-all.c: Move init of irqchip_inject_ioctl out of kvm_irqchip_create() Date: Tue, 14 Aug 2012 16:14:35 +0300 Message-ID: <502A4F3B.7080705@redhat.com> References: <1344272705-17825-1-git-send-email-peter.maydell@linaro.org> <5029FF4B.8040001@web.de> <502A2FFA.1080604@redhat.com> <502A30E7.9090504@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Peter Maydell , Marcelo Tosatti , qemu-devel@nongnu.org, kvm@vger.kernel.org, patches@linaro.org To: Jan Kiszka Return-path: In-Reply-To: <502A30E7.9090504@siemens.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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. -- error compiling committee.c: too many arguments to function