Received: by 10.223.176.5 with SMTP id f5csp2141567wra; Wed, 31 Jan 2018 17:55:54 -0800 (PST) X-Google-Smtp-Source: AH8x2274xzB94jpM7F18FjAhcOMfQng40Cq1XJtkEgS9KWo8mc1P6NXLDqZViGLA4o0VAVajC0VM X-Received: by 10.98.226.24 with SMTP id a24mr35633733pfi.192.1517450154598; Wed, 31 Jan 2018 17:55:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517450154; cv=none; d=google.com; s=arc-20160816; b=ItyIiBfyMhGjKle/GNJiFwriqTxIhpTOQvMKGrpgEOLIJQt8oAwxApyuyrdSghoqPa 1zUgCGuXahWlSbdkvZ+Lo845b1ANvV/uvs/P10SYLivjt3Ois9tIBjCdQbkJRKomax3J hq2Qfvi3QH1bn2Bq9LOWyOox2L/g5lDFWox6mINGZhbATBXWB11bLnuiMF8fi4Vi4/Eh eXto1M2xMY94HwK2ZxbSrgi0h95mG+QQhou12l51bAMur5Co3TIFxjBBRArKOuH3D06s LVmQTj0nHio3YNNdVHCTDVeC+DkBfAEGOBTXQmJ3rJqkjT4ezoy7nnfjp3AapP7vJyuG PN2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=p7177lK4YvQYMsXRuyPyB8Om7GBxorcx14xFsCZu3hs=; b=UPt6BbAAicBR8bK2BdzQuezIYAFPcBm8zktax125e2R3GVUVJevXyg3ZLj+f98x3Wo ob0IY73rOpKzhlO/hzl6FXgCcZdldtGbjuMlo7L1U2u7Ogh9vT3woluh92fMUrDqGjMn szJJlg3yVD/dsDoKuJblP9mLuaNIzkg5CSv/HI8eN22SLlYilTAsh/+d9Q0QwRgLeGTd oKKuDYhWA+WHZs4OUie9THRUrWbyLTLMvLMKoJwm4hWdoM3iIZV3uKoKglvqpkI9hJwg xkw+8UsEwZ+VWup6chI844QA61/K6Bw5askWzCtqTBcqiaQLQtDWojH8gMa1FhNrEM73 KBZQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b=l7aJ2UaL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x6-v6si4179019plr.80.2018.01.31.17.55.40; Wed, 31 Jan 2018 17:55:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b=l7aJ2UaL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932200AbeBABzR (ORCPT + 99 others); Wed, 31 Jan 2018 20:55:17 -0500 Received: from ozlabs.org ([103.22.144.67]:50235 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932137AbeBABzP (ORCPT ); Wed, 31 Jan 2018 20:55:15 -0500 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 3zX38x0hZzz9sPk; Thu, 1 Feb 2018 12:55:13 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=canb.auug.org.au; s=201702; t=1517450113; bh=aPrLtJ/RujijEcV5ODAlO9UcTBgMGUJj+AKHI6q57oM=; h=Date:From:To:Cc:Subject:From; b=l7aJ2UaL8x76Mmb32iISnwPs0yBN0sRURdsotX8pfLAOwUGqxbTAe6RbFixYAedFK T8NJIDNFi3lS6swxRziZL7iW0eBCOeZ98aR2RIog68Lq3Wn1yuc/5kWboc6UGLUwIr 3tLujYmL8EeeeTUxUF+Qj5Kn+rKfu4fjvnGrcGtne7erunh9gi9v4yel4mK7SKPGi5 4gGGOLrIHfxTx6GZ+EqIkDaUS5xKUuCWBdAx07shH2Ls+TFT6v0svxvjxT2ti0PnJW TujLbkdj/J0GcEJLspOzC+9FAoIqawC/3kIc4Q3VKJXUvq/KfwK2x5HbrgszvKs1J+ fVmVgz/bsTrMA== Date: Thu, 1 Feb 2018 12:55:12 +1100 From: Stephen Rothwell To: Paolo Bonzini , Radim =?UTF-8?B?S3LEjW3DocWZ?= , KVM Cc: Linux-Next Mailing List , Linux Kernel Mailing List , Christoffer Dall Subject: linux-next: manual merge of the kvm tree with Linus' tree Message-ID: <20180201125512.7bc96674@canb.auug.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, Today's linux-next merge of the kvm tree got a conflict in: virt/kvm/arm/arch_timer.c between commit: 36e5cfd410ad ("KVM: arm/arm64: Properly handle arch-timer IRQs after vtimer_save_state") from Linus' tree and commits: 70450a9fbe06 ("KVM: arm/arm64: Don't cache the timer IRQ level") 13e59ece5b30 ("KVM: arm/arm64: Fix incorrect timer_is_pending logic") from the kvm tree. I fixed it up (I think - see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc virt/kvm/arm/arch_timer.c index cc29a8148328,fb6bd9b9845e..000000000000 --- a/virt/kvm/arm/arch_timer.c +++ b/virt/kvm/arm/arch_timer.c @@@ -92,27 -92,18 +92,26 @@@ static irqreturn_t kvm_arch_timer_handl { struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id; struct arch_timer_context *vtimer; + u32 cnt_ctl; - if (!vcpu) { - pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n"); - return IRQ_NONE; - } + /* + * We may see a timer interrupt after vcpu_put() has been called which + * sets the CPU's vcpu pointer to NULL, because even though the timer + * has been disabled in vtimer_save_state(), the hardware interrupt + * signal may not have been retired from the interrupt controller yet. + */ + if (!vcpu) + return IRQ_HANDLED; vtimer = vcpu_vtimer(vcpu); - if (!vtimer->irq.level) { - cnt_ctl = read_sysreg_el0(cntv_ctl); - cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT | - ARCH_TIMER_CTRL_IT_MASK; - if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT)) - kvm_timer_update_irq(vcpu, true, vtimer); - } - - if (unlikely(!irqchip_in_kernel(vcpu->kvm))) - if (kvm_timer_should_fire(vtimer)) ++ cnt_ctl = read_sysreg_el0(cntv_ctl); ++ cnt_ctl &= ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT | ++ ARCH_TIMER_CTRL_IT_MASK; ++ if (cnt_ctl == (ARCH_TIMER_CTRL_ENABLE | ARCH_TIMER_CTRL_IT_STAT)) + kvm_timer_update_irq(vcpu, true, vtimer); + + if (static_branch_unlikely(&userspace_irqchip_in_use) && + unlikely(!irqchip_in_kernel(vcpu->kvm))) kvm_vtimer_update_mask_user(vcpu); return IRQ_HANDLED;