From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6BA0D10FF for ; Thu, 15 Jun 2023 08:36:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CCD7C433C8; Thu, 15 Jun 2023 08:36:17 +0000 (UTC) Date: Thu, 15 Jun 2023 09:36:14 +0100 From: Catalin Marinas To: Oliver Upton Cc: kvmarm@lists.linux.dev, Marc Zyngier , James Morse , Suzuki K Poulose , Zenghui Yu , Will Deacon , linux-arm-kernel@lists.infradead.org, Darren Hart , D Scott Phillips Subject: Re: [PATCH 0/3] KVM: arm64: Work around Ampere1 erratum AC03_CPU_38 Message-ID: References: <20230609220104.1836988-1-oliver.upton@linux.dev> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Jun 14, 2023 at 11:06:40PM +0000, Oliver Upton wrote: > Hey Catalin, > > On Wed, Jun 14, 2023 at 05:57:55PM +0100, Catalin Marinas wrote: > > On Fri, Jun 09, 2023 at 10:01:01PM +0000, Oliver Upton wrote: > > > Small series to work around a CPU erratum on AmpereOne. While the > > > implementation does not advertise support for FEAT_HAFDBS (due to > > > another erratum), the associated control bits do not have RES0 behavior > > > as required by the architecture. > > > > > > Usage of HAFDBS at stage-1 is unaffected, since HA and HD are only > > > enabled on implementations that advertise the feature. However, KVM > > > relies on HA having RES0 semantics if the feature isn't implemented. The > > > end result is that KVM enables a broken hardware access flag > > > implementation that could lead to correctness issues. > > > > Just curious, what's the correctness issue here? The access flag is > > mostly indicative of which pages are old for swapping out/discarding. > > It's not like the dirty state which would be dangerous if we get wrong. > > I probably could have helped out by giving the full context. > > The software-observable behavior on this system is that the A or D > updates could arrive after a PTE has been marked as invalid, which could > corrupt software metadata stuffed into the page tables. We do exactly > that at stage-2 in KVM for parallel fault handling, where a magic value > indicates a PTE is being updated by another thread. Ah, ok, that's dangerous indeed. Thanks for the details (you may want to add them in the patch description or the erratum kconfig entry). -- Catalin 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 77B30EB64D9 for ; Thu, 15 Jun 2023 08:36:41 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=IvBRieOI3BYdV2SBpxpebFibVYQwjN1Qq++a7Qx/aB0=; b=tcRLv93I1/16sV xTGFCU2YiBEZB9bRaTUm852TSmbx3/BQaDUhT38VlMTwk+172cUZzquPBdCV899ohJeKvWQzrI0Qd fQIb7RVcRYQkp+l4AIsv96mnlaJP1+QJvrEW7x8cEFfJCsoLIkGDU9ogfkM7RewtU4H0wjgvNW+lP FPs17vzQnXhToSbNkamjMm3Pm6duJ9PMlz8MgnmGtZ05p5NaSa/qvi1xwSHe+fVQCqWZctNxRw16E fz6nevFQ5JXmHhS+Fr8CwzZHhrDN8RZlsRvcjgyK01XJOWSF6NpIqdJIeCg67yuUXHUxdk00jhEBd BuISlzSr7BuF5gKzBgOQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q9iSs-00EBOP-1R; Thu, 15 Jun 2023 08:36:22 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q9iSq-00EBNw-0I for linux-arm-kernel@lists.infradead.org; Thu, 15 Jun 2023 08:36:21 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7530D60FA4; Thu, 15 Jun 2023 08:36:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CCD7C433C8; Thu, 15 Jun 2023 08:36:17 +0000 (UTC) Date: Thu, 15 Jun 2023 09:36:14 +0100 From: Catalin Marinas To: Oliver Upton Cc: kvmarm@lists.linux.dev, Marc Zyngier , James Morse , Suzuki K Poulose , Zenghui Yu , Will Deacon , linux-arm-kernel@lists.infradead.org, Darren Hart , D Scott Phillips Subject: Re: [PATCH 0/3] KVM: arm64: Work around Ampere1 erratum AC03_CPU_38 Message-ID: References: <20230609220104.1836988-1-oliver.upton@linux.dev> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230615_013620_168208_70CDFB1C X-CRM114-Status: GOOD ( 24.85 ) 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 Wed, Jun 14, 2023 at 11:06:40PM +0000, Oliver Upton wrote: > Hey Catalin, > > On Wed, Jun 14, 2023 at 05:57:55PM +0100, Catalin Marinas wrote: > > On Fri, Jun 09, 2023 at 10:01:01PM +0000, Oliver Upton wrote: > > > Small series to work around a CPU erratum on AmpereOne. While the > > > implementation does not advertise support for FEAT_HAFDBS (due to > > > another erratum), the associated control bits do not have RES0 behavior > > > as required by the architecture. > > > > > > Usage of HAFDBS at stage-1 is unaffected, since HA and HD are only > > > enabled on implementations that advertise the feature. However, KVM > > > relies on HA having RES0 semantics if the feature isn't implemented. The > > > end result is that KVM enables a broken hardware access flag > > > implementation that could lead to correctness issues. > > > > Just curious, what's the correctness issue here? The access flag is > > mostly indicative of which pages are old for swapping out/discarding. > > It's not like the dirty state which would be dangerous if we get wrong. > > I probably could have helped out by giving the full context. > > The software-observable behavior on this system is that the A or D > updates could arrive after a PTE has been marked as invalid, which could > corrupt software metadata stuffed into the page tables. We do exactly > that at stage-2 in KVM for parallel fault handling, where a magic value > indicates a PTE is being updated by another thread. Ah, ok, that's dangerous indeed. Thanks for the details (you may want to add them in the patch description or the erratum kconfig entry). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel