From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] kvm-all.c: Move init of irqchip_inject_ioctl out of kvm_irqchip_create() Date: Tue, 14 Aug 2012 15:36:42 +0200 Message-ID: <502A546A.5070600@siemens.com> References: <1344272705-17825-1-git-send-email-peter.maydell@linaro.org> <5029FF4B.8040001@web.de> <502A2FFA.1080604@redhat.com> <502A30E7.9090504@siemens.com> <502A4F3B.7080705@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Peter Maydell , "qemu-devel@nongnu.org" , "patches@linaro.org" , Marcelo Tosatti , "kvm@vger.kernel.org" To: Avi Kivity Return-path: Received: from david.siemens.de ([192.35.17.14]:28325 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751119Ab2HNNgt (ORCPT ); Tue, 14 Aug 2012 09:36:49 -0400 In-Reply-To: <502A4F3B.7080705@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1HIg-0000UL-FV for qemu-devel@nongnu.org; Tue, 14 Aug 2012 09:36:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1HIb-0001ym-Iv for qemu-devel@nongnu.org; Tue, 14 Aug 2012 09:36:50 -0400 Received: from david.siemens.de ([192.35.17.14]:30935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1HIb-0001yf-8h for qemu-devel@nongnu.org; Tue, 14 Aug 2012 09:36:45 -0400 Message-ID: <502A546A.5070600@siemens.com> Date: Tue, 14 Aug 2012 15:36:42 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1344272705-17825-1-git-send-email-peter.maydell@linaro.org> <5029FF4B.8040001@web.de> <502A2FFA.1080604@redhat.com> <502A30E7.9090504@siemens.com> <502A4F3B.7080705@redhat.com> In-Reply-To: <502A4F3B.7080705@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] kvm-all.c: Move init of irqchip_inject_ioctl out of kvm_irqchip_create() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Peter Maydell , Marcelo Tosatti , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , "patches@linaro.org" 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