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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT 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 924E8C282C7 for ; Thu, 31 Jan 2019 09:27:15 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 6E0A920881 for ; Thu, 31 Jan 2019 09:27:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="M42XsRLb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6E0A920881 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=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: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=gfmuEMKrHJn6OM+kXpfjSkYG7dSezuy+yQEF3PwkpsQ=; b=M42XsRLbn9iI/P ZhtIdegns0nphcnJ7X1xHguXG7b2Apez2hzo2OvIhHHJFcA0be4bGoPZHfkpGlXpqoketUk7/cy3+ kGS0A+Cuxi0u0aLunXtPIgF2DBgotSzGHJqbc2jeGjY/JaLbGHPaA7dGaXdeasbSw0INXPv8GCBdw x70UN6+qnZ2GjrHd8iac0XC3DDsaPBqOat8rYzbBOcHVKKcOaXZDP1yTCOExHPmSNcSRY7RpHt3J2 yGDEQ76a7kaou4v4GNeQqWGaBfUDVgnym1giNITwLdppWm5j4d54rpohqEDVZw2l7hmgHgfs9/rnj q9PeXiZTvFG4fXIJ4KSg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gp8cr-0007pt-PW; Thu, 31 Jan 2019 09:27:13 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1gp8co-0007pZ-VR for linux-arm-kernel@lists.infradead.org; Thu, 31 Jan 2019 09:27:12 +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 952BFA78; Thu, 31 Jan 2019 01:27:08 -0800 (PST) Received: from localhost (e113682-lin.copenhagen.arm.com [10.32.144.41]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 05DE23F71E; Thu, 31 Jan 2019 01:27:07 -0800 (PST) Date: Thu, 31 Jan 2019 10:27:06 +0100 From: Christoffer Dall To: Julien Thierry Subject: Re: [PATCH v9 01/26] arm64: Fix HCR.TGE status for NMI contexts Message-ID: <20190131092706.GN13482@e113682-lin.lund.arm.com> References: <1548084825-8803-1-git-send-email-julien.thierry@arm.com> <1548084825-8803-2-git-send-email-julien.thierry@arm.com> <8e8c4f5b-5b83-7bbc-1b84-36d68e210968@arm.com> <847c54ef-ea41-eea5-8aff-72e0cea465f8@arm.com> <20190131081900.GM13482@e113682-lin.lund.arm.com> <32af4a5c-7aeb-0171-1b4a-2cbee5f78bca@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <32af4a5c-7aeb-0171-1b4a-2cbee5f78bca@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190131_012711_013939_FEE9D51F X-CRM114-Status: GOOD ( 17.65 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, linux-arch@vger.kernel.org, daniel.thompson@linaro.org, Arnd Bergmann , marc.zyngier@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, stable@vger.kernel.org, James Morse , joel@joelfernandes.org, 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+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jan 31, 2019 at 08:56:04AM +0000, Julien Thierry wrote: > > > On 31/01/2019 08:19, Christoffer Dall wrote: > > On Mon, Jan 28, 2019 at 03:42:42PM +0000, Julien Thierry wrote: > >> Hi James, > >> > >> On 28/01/2019 11:48, James Morse wrote: > >>> Hi Julien, > >>> > >>> On 21/01/2019 15:33, Julien Thierry wrote: > >>>> When using VHE, the host needs to clear HCR_EL2.TGE bit in order > >>>> to interract with guest TLBs, switching from EL2&0 translation regime > >>> > >>> (interact) > >>> > >>> > >>>> to EL1&0. > >>>> > >>>> However, some non-maskable asynchronous event could happen while TGE is > >>>> cleared like SDEI. Because of this address translation operations > >>>> relying on EL2&0 translation regime could fail (tlb invalidation, > >>>> userspace access, ...). > >>>> > >>>> Fix this by properly setting HCR_EL2.TGE when entering NMI context and > >>>> clear it if necessary when returning to the interrupted context. > >>> > >>> Yes please. This would not have been fun to debug! > >>> > >>> Reviewed-by: James Morse > >>> > >>> > >> > >> Thanks. > >> > >>> > >>> I was looking for why we need core code to do this, instead of updating the > >>> arch's call sites. Your 'irqdesc: Add domain handlers for NMIs' patch (pointed > >>> to from the cover letter) is the reason: core-code calls nmi_enter()/nmi_exit() > >>> itself. > >>> > >> > >> Yes, that's the main reason. > >> > > I wondered the same thing, but I don't understand the explanation :( > > > > Why can't we do a local_daif_mask() around the (very small) calls that > > clear TGE instead? > > > > That would protect against the pseudo-NMIs, but you can still get an > SDEI at that point even with all daif bits set. Or did I misunderstand > how SDEI works? > I don't know the details of SDEI. From looking at this patch, the logical conclusion would be that SDEIs can then only be delivered once we've called nmi_enter, but since we don't call this directly from the code that clears TGE for doing guest TLB invalidation (or do we?) then masking interrupts at the PSTATE level should be sufficient. Surely I'm missing some part of the bigger picture here. Thanks, Christoffer _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel