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 E65E9C5DF97 for ; Sat, 22 Aug 2026 08:12:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XJ1sRYzSe5gmp5y69f27mpBK8RaS1RNxeM0V94UPPv8=; b=U6KcEWQcQUfytulyaXcudXhOsS J74u9qXtPEKqz6n81ajXZpQf6f548nuX8VqmEWRidLlbYxk0NemxDtMJa1FM3GRznlYnq+l1/bCTu DMTzofnjxo71IdaYYlW9KLWSr7mxSQ/vlX1H74sMhoWdpFM8MlvxYwtsrmz0e8bLjXA0Z8ZZUiGSG sM4igELcSGBBS2OBSnJDXap1/v0OL1ZRy9dT4+rhisoFc5YbRQAbrGQfmT2tk/FsrX4+ZfYnmSL9e IvVVpu+SBiUOWk6nKawWtEkvqd1KJq9y/7UymSaZaz35XSI307/dAjo6ypdpU7KYSU3dFLbA1aU/L IhrJfgKw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wxgqD-0000000ENbN-3Qcr; Sat, 22 Aug 2026 08:12:37 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wxgqB-0000000ENbH-39us for linux-arm-kernel@lists.infradead.org; Sat, 22 Aug 2026 08:12:35 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id E4FA0600E2; Sat, 22 Aug 2026 08:12:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AAFD1F000E9; Sat, 22 Aug 2026 08:12:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787386354; bh=XJ1sRYzSe5gmp5y69f27mpBK8RaS1RNxeM0V94UPPv8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=VzsFlLlZyTQaI+HK8Ko3rj3I/ZeYtiIgyEfqtFLzRZ67OtlQZjiop54B44PP5wcJO eoId8gVC+ctFYjtwC9ThjbOO/5RpXNupkZK8dgmUAo5gKl0+4boQVJSRwj6GvA49vW kdiTQHyzX7MwNCHl6RD23j/zNK8ApoomHiyc0v1MZZOcxyMxKtceBd9UURagUO8XDK VsYjYH8uguYdPAK9VV48NfhkAaYnHSeCnPdjQYnJA2YJNy73MTbX+Ko4eWY5J07axK 1Pld7LM5Ld+dKiZxIieNz8I9mQUac6Td54S2lJg/8AOFb45IjB0N/Y9p7TqO6DVY+c gHKJ+EVKc9nRw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wxgq8-00000000ECd-2A2P; Sat, 22 Aug 2026 08:12:32 +0000 Date: Sat, 22 Aug 2026 09:12:32 +0100 Message-ID: <86v7924lqn.wl-maz@kernel.org> From: Marc Zyngier To: "Lorenzo Stoakes (ARM)" Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Steffen Eiden , Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Fuad Tabba , Shen Yongchao , Karl Mehltretter , Wei-Lin Chang , stable@vger.kernel.org Subject: Re: [PATCH v3 2/2] KVM: arm64: nv: Delay freeing of shadow S2 structures until VM destruction In-Reply-To: References: <20260821161829.1032561-1-maz@kernel.org> <20260821161829.1032561-3-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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ljs@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, seiden@linux.ibm.com, joey.gouly@arm.com, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.com, fuad.tabba@linux.dev, grayhat@foxmail.com, kmehltretter@gmail.com, weilin.chang@arm.com, stable@vger.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-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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 21 Aug 2026 19:15:45 +0100, "Lorenzo Stoakes (ARM)" wrote: > > On Fri, Aug 21, 2026 at 05:18:29PM +0100, Marc Zyngier wrote: > > We free the shadow S2 structures from kvm_arch_flush_shadow_all(), which > > is a Bad Idea(tm). Freeing the page tables is fair game (this is what > > this callback is for), but freeing the container that could still be > > referenced by another part of the system is not great. > > Yes. > > > > > Instead, grow separate destructors that gets called when we tear the VM > > down for good. From there, we can nuke both the individual MMUs as well > > as the global array that points to them, safe in the knowledge that the > > vcpus themselves have been destroyed already. > > > > Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures") > > Signed-off-by: Marc Zyngier > > LGTM so: > > Reviewed-by: Lorenzo Stoakes (ARM) Thanks. > A couple thoughts/questions below. [...] > > @@ -1310,16 +1319,12 @@ void kvm_nested_s2_flush(struct kvm *kvm) > > > > void kvm_arch_flush_shadow_all(struct kvm *kvm) > > { > > - for (int i = kvm->arch.nested_mmus_size - 1; i >= 0; i--) { > > + for (int i = 0; i < kvm->arch.nested_mmus_size; i++) { > > Hmm why this was in reverse before? :) I guess some product of the > kvfree() bit or maybe something else? We allocate s2_mmus in S2_MMU_PER_VCPU chunks. Which means that it complicates the freeing of the these structures, as they can only be freed once all S2 PTs of that chunk have been freed. We have three options: - scan forward, and use complicated logic to work out that you have freed the last PTs of a chunk, freeing with a negative offset from the current point in the loop. Works, but hard to reason about in fewer than 3 seconds. - scan backward, use simpler logic to ensure you have reached the beginning of a chunk, nuke it. - have two loops, one for the PTs, one for the MMUs. That's what we end-up with due to the different garbage collection phases. Cheers, M. -- Without deviation from the norm, progress is not possible.