From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 023ECC43468 for ; Mon, 21 Sep 2020 13:44:55 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9A08D2084C for ; Mon, 21 Sep 2020 13:44:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="KkJCV/5m"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="WxRp7fNz" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A08D2084C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.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:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=g148ALoFXW5IufBWTRtDPSL1PfWtOyoXodcheDhf2Kw=; b=KkJCV/5m6cNahgyza/XenF3OU uBdkNNPicn9trczlOBMCR0GDes61Fz3bnOtrQ19p+8Im93jpO+o+aK8R4TH4OCua33kBEUW+otvnJ IrmF4CgEtMjJY4b4x2rhOaVI05GQpz5d2EiNjRo6Gxxw9uyZiG8Ma0hrx0Qn1wNhOq2jJYrM6XEjs hobFhXWzchdOHhsd4H8u/a55oxNGehtvxLG68e//JJvJb86x0lxLmxJVmPM0GOUwcGp+iGRGGzomb m4UvSeC8arP1yOUOKNpFBUwuCAPu4djlxZxDoSfu4NlOqZGI/JkEUndZ1jLo7cY97HV8Jd96Z/O9b KU6HopwTQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKM64-0002cY-RN; Mon, 21 Sep 2020 13:43:12 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kKM61-0002c6-S0 for linux-arm-kernel@lists.infradead.org; Mon, 21 Sep 2020 13:43:11 +0000 Received: from willie-the-truck (236.31.169.217.in-addr.arpa [217.169.31.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 335472084C; Mon, 21 Sep 2020 13:43:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1600695788; bh=ppWgQwIPJFgXvpl5SyaBDqV8l2T0GGovdfeRTgIHCFU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WxRp7fNzBJpKQt2ftVmrIe0M00opXLZn+F2d5mDdpSKGn8lUe/l/M4uRs6n6sREdy bW0hA+DLr0AjQqCJBgrHPFgxzbq84ceM4vkef6/Rx84et6Iin19dgiliB/AzP8PonQ 4ut8OFK2UunvFo4cAYtKyJOqaJGFdcG9RYMVTRe0= Date: Mon, 21 Sep 2020 14:43:02 +0100 From: Will Deacon To: Alexandru Elisei Subject: Re: [PATCH v6 5/7] KVM: arm64: pmu: Make overflow handler NMI safe Message-ID: <20200921134301.GJ2139@willie-the-truck> References: <20200819133419.526889-1-alexandru.elisei@arm.com> <20200819133419.526889-6-alexandru.elisei@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200819133419.526889-6-alexandru.elisei@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200921_094310_000586_4FE47AA1 X-CRM114-Status: GOOD ( 23.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, sumit.garg@linaro.org, kvm@vger.kernel.org, Julien Thierry , Marc Zyngier , maz@kernel.org, Suzuki K Pouloze , Will Deacon , linux-kernel@vger.kernel.org, swboyd@chromium.org, James Morse , Julien Thierry , catalin.marinas@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Aug 19, 2020 at 02:34:17PM +0100, Alexandru Elisei wrote: > From: Julien Thierry > > kvm_vcpu_kick() is not NMI safe. When the overflow handler is called from > NMI context, defer waking the vcpu to an irq_work queue. > > Cc: Julien Thierry > Cc: Marc Zyngier > Cc: Will Deacon > Cc: Mark Rutland > Cc: Catalin Marinas > Cc: James Morse > Cc: Suzuki K Pouloze > Cc: kvm@vger.kernel.org > Cc: kvmarm@lists.cs.columbia.edu > Signed-off-by: Julien Thierry > Signed-off-by: Alexandru Elisei > --- > arch/arm64/kvm/pmu-emul.c | 25 ++++++++++++++++++++++++- > include/kvm/arm_pmu.h | 1 + > 2 files changed, 25 insertions(+), 1 deletion(-) I'd like an Ack from the KVM side on this one, but some minor comments inline. > diff --git a/arch/arm64/kvm/pmu-emul.c b/arch/arm64/kvm/pmu-emul.c > index f0d0312c0a55..30268397ed06 100644 > --- a/arch/arm64/kvm/pmu-emul.c > +++ b/arch/arm64/kvm/pmu-emul.c > @@ -433,6 +433,22 @@ void kvm_pmu_sync_hwstate(struct kvm_vcpu *vcpu) > kvm_pmu_update_state(vcpu); > } > > +/** > + * When perf interrupt is an NMI, we cannot safely notify the vcpu corresponding > + * to the event. > + * This is why we need a callback to do it once outside of the NMI context. > + */ > +static void kvm_pmu_perf_overflow_notify_vcpu(struct irq_work *work) > +{ > + struct kvm_vcpu *vcpu; > + struct kvm_pmu *pmu; > + > + pmu = container_of(work, struct kvm_pmu, overflow_work); > + vcpu = kvm_pmc_to_vcpu(&pmu->pmc[0]); Can you spell this kvm_pmc_to_vcpu(pmu->pmc); ? > + > + kvm_vcpu_kick(vcpu); How do we guarantee that the vCPU is still around by the time this runs? Sorry to ask such a horrible question, but I don't see anything associating the workqueue with the lifetime of the vCPU. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel