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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 93CA4C76196 for ; Fri, 7 Apr 2023 11:38:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=c6hOb41hEoyL2/3WhSUGIoZytXuQ85tBSSQT4B0kg3o=; b=LO72v00/mDyeo7 NqQpvq5xdWU100y7mKtAQwZfeB4amhCn0NTZmOmXdZEiE4OamtoYa1mbFFKuCEiuEu4CVhlAlqzQA VXDw00VdKhjhGTIIciBm2YJvS2ZH7rRKEWb8oAkyQY5SP/ShCny3VgTBjALj+BqjFqiuJYeM5pYED rDS0GeG1B1GqpX93oSTHuxnZ+8cp7Y7RR9OI6yzURzEjeW1Qe4K1wELG4uJFaV3ZfjfngSNTTGDqf nBYXJ9czOLIbJDcyjbf+Y+voRP0i7OxWa+gryaJoiPPyzmntg9O2O8dFTDuMpl1qhUUi9yIOc4tHX 7pgNLnQ1RgYFbny9pZhA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pkkP9-00A6YT-18; Fri, 07 Apr 2023 11:37:19 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pkkP5-00A6XS-1i for linux-arm-kernel@lists.infradead.org; Fri, 07 Apr 2023 11:37:16 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C23AE6114D; Fri, 7 Apr 2023 11:37:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B185C433D2; Fri, 7 Apr 2023 11:37:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1680867434; bh=gKTl3mxlnakzRJaSe8tQ31Hb1W+j6AYUGWXNgGKNPjo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=EKjJJ5JOzN5eBsDjVyBn1tGD4u2/BSgbVDSMdMHbmsrWQYTP3WCBafIbKEp3WxN9t cmXxs1cv3E7VR7IwQjZPkrt6hxJQ/5QOjdbp4rolHet7ZmSNLBcG1eRSbSVvAcLEsw 65OAr7Pq4nTpCfmvXXvk/YzofBTajAQMnM8kAOuaUuLlApk7eg1ZxbyycDDoPnvTVD klUJUlVH70h2krCXMZYZA7HTULlLRLhYngv3gWbj/MzH74kgEpHiLmq/E5GFOQu0o3 Jv6jQNIAa8wxMcQeoYOiKPIi3Z6ne+yGRQzWYxSpgxeA8uJ9XY3X5e96HQ+JhlGrTx XXDRhyKnGe2CQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pkkP1-006geg-LK; Fri, 07 Apr 2023 12:37:11 +0100 Date: Fri, 07 Apr 2023 12:37:11 +0100 Message-ID: <87lej36hzs.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Suzuki K Poulose , Zenghui Yu , Will Deacon Subject: Re: [PATCH 1/2] KVM: arm64: nvhe: Synchronise with page table walker on MMU update In-Reply-To: <87mt3k53x9.wl-maz@kernel.org> References: <20230330100419.1436629-1-maz@kernel.org> <20230330100419.1436629-2-maz@kernel.org> <87mt3k53x9.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oliver.upton@linux.dev, kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, will@kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230407_043715_663701_A39D909C X-CRM114-Status: GOOD ( 33.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Fri, 07 Apr 2023 12:26:26 +0100, Marc Zyngier wrote: > > Hi Oliver, > > On Thu, 06 Apr 2023 17:56:31 +0100, > Oliver Upton wrote: > > > > Hey Marc, > > > > On Thu, Mar 30, 2023 at 11:04:18AM +0100, Marc Zyngier wrote: > > > When taking an exception between the EL1&0 translation regime and > > > the EL2 translation regime, the page table walker is allowed to > > > complete the walks started from EL0 or EL1 while running at EL2. > > > > > > It means that altering the system registers that define the EL1&0 > > > translation regime is fraught with danger *unless* we wait for > > > the completion of such walk with a DSB (R_LFHQG and subsequent > > > statements in the ARM ARM). We already did the right thing for > > > other external agents (SPE, TRBE), but not the PTW. > > > > > > In the case of nVHE, this is a bit involved, as there are a number > > > of situations where this can happen (such as switching between > > > host and guest, invalidating TLBs...). > > > > I'm assuming that the dsb(ishst) done in some of the other TLB > > invalidation handlers is sufficient, as R_LFHQG does not describe the > > scope of the DSB (i.e. loads and/or stores). Nonetheless, short of any > > special serialization rules, it seems probable for the PTW to have both > > outstanding loads and stores. > > I too find the definition pretty light. My gut feeling is that we're > not really trying to synchronise against either loads or stores. We > are simply waiting for the PTW to complete (or give up) potential > speculative walks. > > For TLBIs, we want to make sure that prior writes to the PTs are > observable, specially as we perform a broadcast invalidation. > > But for external agents, we seem to always rely on an dsb(nsh), such > as for TRBE and SPE. My take is that if it is enough for them, it > should be enough for the PTW. I'll also add that dsb(nsh) orders both reads and writes either side of the barrier. However, I finally get your point about the TLBI code. It only orders stores either side of the barrier, and I'm starting to wonder whether we should upgrade it to dsb(ish)... Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel