From patchwork Tue Apr 25 07:38:56 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 754601 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wBw8T4nrqz9s80 for ; Tue, 25 Apr 2017 17:39:37 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="kZ2PIsUy"; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=9v5Wz5UIVu4c8RXc9ST7jXw4GQWgIhj1Ri+KuuAyEuw=; b=kZ2PIsUysBaAnF +OPlSwDpaC+gb+tFllAurFJNT7iPTUHpa+Le+cgh3emcJDarYTq9Tv30JGbOio5ZeupCiLe0L6I0O 3r4QSA3YGvKHhk8y9Iwz7wiRD7wfmi0pXgpAgZth/CzZYwcHMgjin17b1mE+y/CAOzfz8lwYoVYa5 ZkX0W9ML4NaBIdEPRsTeb+JOUdfxRnByNLOt+tYum+L5naeRDrfi5x1NQzeZWWj/WlY9l3i5ObuMY M6cumkpm/iD/mX1jGXSNLS+1mv3dFrciaejiDwEEiNqs44Lw0G72pZCP4F12Uozcx0AL9P+H25n01 NQhHPHt4XJ1N7RyYJcMA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1d2v4S-0004Cc-8C; Tue, 25 Apr 2017 07:39:36 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1d2v4G-0003y5-7z; Tue, 25 Apr 2017 07:39:25 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3E4AA344; Tue, 25 Apr 2017 00:39:00 -0700 (PDT) Received: from [10.1.207.16] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8A7273F3E1; Tue, 25 Apr 2017 00:38:57 -0700 (PDT) Subject: Re: [PATCH V9 1/3] irq: Allow to pass the IRQF_TIMER flag with percpu irq request To: Daniel Lezcano References: <1493042494-14057-1-git-send-email-daniel.lezcano@linaro.org> <398f3f3d-c567-0f1f-1a43-9b8d5805d5fd@arm.com> <20170424185909.GD2137@mai> <92e2a022-93d4-d4f3-78af-c9b5d51bb867@arm.com> <20170424195948.GE2137@mai> From: Marc Zyngier Organization: ARM Ltd Message-ID: <16042494-2e67-e1a5-b9f6-af57e349d8a7@arm.com> Date: Tue, 25 Apr 2017 08:38:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170424195948.GE2137@mai> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170425_003924_327083_D82853EB X-CRM114-Status: GOOD ( 22.31 ) X-Spam-Score: -6.9 (------) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-6.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [217.140.101.70 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , linux-samsung-soc@vger.kernel.org, kernel@stlinux.com, kvm@vger.kernel.org, =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Vineet Gupta , Patrice Chotard , Krzysztof Kozlowski , linux-kernel@vger.kernel.org, Javier Martinez Canillas , Kukjin Kim , linux-arm-kernel@lists.infradead.org, Paolo Bonzini , tglx@linutronix.de, linux-snps-arc@lists.infradead.org, kvmarm@lists.cs.columbia.edu, Christoffer Dall Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On 24/04/17 20:59, Daniel Lezcano wrote: > On Mon, Apr 24, 2017 at 08:14:54PM +0100, Marc Zyngier wrote: >> On 24/04/17 19:59, Daniel Lezcano wrote: >>> On Mon, Apr 24, 2017 at 07:46:43PM +0100, Marc Zyngier wrote: >>>> On 24/04/17 15:01, Daniel Lezcano wrote: >>>>> In the next changes, we track when the interrupts occur in order to >>>>> statistically compute when is supposed to happen the next interrupt. >>>>> >>>>> In all the interruptions, it does not make sense to store the timer interrupt >>>>> occurences and try to predict the next interrupt as when know the expiration >>>>> time. >>>>> >>>>> The request_irq() has a irq flags parameter and the timer drivers use it to >>>>> pass the IRQF_TIMER flag, letting us know the interrupt is coming from a timer. >>>>> Based on this flag, we can discard these interrupts when tracking them. >>>>> >>>>> But, the API request_percpu_irq does not allow to pass a flag, hence specifying >>>>> if the interrupt type is a timer. >>>>> >>>>> Add a function request_percpu_irq_flags() where we can specify the flags. The >>>>> request_percpu_irq() function is changed to be a wrapper to >>>>> request_percpu_irq_flags() passing a zero flag parameter. >>>>> >>>>> Change the timers using request_percpu_irq() to use request_percpu_irq_flags() >>>>> instead with the IRQF_TIMER flag set. >>>>> >>>>> For now, in order to prevent a misusage of this parameter, only the IRQF_TIMER >>>>> flag (or zero) is a valid parameter to be passed to the >>>>> request_percpu_irq_flags() function. >>>> >>>> [...] >>>> >>>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c >>>>> index 35d7100..602e0a8 100644 >>>>> --- a/virt/kvm/arm/arch_timer.c >>>>> +++ b/virt/kvm/arm/arch_timer.c >>>>> @@ -523,8 +523,9 @@ int kvm_timer_hyp_init(void) >>>>> host_vtimer_irq_flags = IRQF_TRIGGER_LOW; >>>>> } >>>>> >>>>> - err = request_percpu_irq(host_vtimer_irq, kvm_arch_timer_handler, >>>>> - "kvm guest timer", kvm_get_running_vcpus()); >>>>> + err = request_percpu_irq_flags(host_vtimer_irq, kvm_arch_timer_handler, >>>>> + IRQF_TIMER, "kvm guest timer", >>>>> + kvm_get_running_vcpus()); >>>>> if (err) { >>>>> kvm_err("kvm_arch_timer: can't request interrupt %d (%d)\n", >>>>> host_vtimer_irq, err); >>>>> >>>> >>>> How is that useful? This timer is controlled by the guest OS, and not >>>> the host kernel. Can you explain how you intend to make use of that >>>> information in this case? >>> >>> Isn't it a source of interruption on the host kernel? >> >> Only to cause an exit of the VM, and not under the control of the host. >> This isn't triggering any timer related action on the host code either. >> >> Your patch series seems to assume some kind of predictability of the >> timer interrupt, which can make sense on the host. Here, this interrupt >> is shared among *all* guests running on this system. >> >> Maybe you could explain why you think this interrupt is relevant to what >> you're trying to achieve? > > If this interrupt does not happen on the host, we don't care. All interrupts happen on the host. There is no such thing as a HW interrupt being directly delivered to a guest (at least so far). The timer is under control of the guest, which uses as it sees fit. When the HW timer expires, the interrupt fires on the host, which re-inject the interrupt in the guest. > The flag IRQF_TIMER is used by the spurious irq handler in the try_one_irq() > function. However the per cpu timer interrupt will be discarded in the function > before because it is per cpu. Right. That's not because this is a timer, but because it is per-cpu. So why do we need this IRQF_TIMER flag, instead of fixing try_one_irq()? > IMO, for consistency reason, adding the IRQF_TIMER makes sense. Other than > that, as the interrupt is not happening on the host, this flag won't be used. > > Do you want to drop this change? No, I'd like to understand the above. Why isn't the following patch doing the right thing? Thanks, M. diff --git a/kernel/irq/spurious.c b/kernel/irq/spurious.c index 061ba7eed4ed..a4a81c6c7602 100644 --- a/kernel/irq/spurious.c +++ b/kernel/irq/spurious.c @@ -72,6 +72,7 @@ static int try_one_irq(struct irq_desc *desc, bool force) * marked polled are excluded from polling. */ if (irq_settings_is_per_cpu(desc) || + irq_settings_is_per_cpu_devid(desc) || irq_settings_is_nested_thread(desc) || irq_settings_is_polled(desc)) goto out;