From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 2E2CC3672A9; Tue, 23 Jun 2026 13:50:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782222652; cv=none; b=WQkJyOwFZAslDpV6DrC7EgvYap9rpGgNM+GEresJ/koAKdMm+zrLD6+QX/qH53YfAgI5pC1YbqGioM0cJl+wYfSKu3Bc9kDzrunO9cPkeLimf5DtWZTiFdiXfpiPjUsWprzLrzg8Ywi2nhKM5H9h+2rQ7FG2LWz6QsKbcL+xUaI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782222652; c=relaxed/simple; bh=MSDzm2EAmzRkBqd5hSTg/HEfwzJGas72unhIzIhD+rU=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=cghv7bRwqMDZoGJLcuQzTtmo+jwwf/vJnMF4TlQ7IeOt5R3vlNyh+5PC85zqBEsxi1KOhkgOfuPw7fKiDjLi11wY/bht7l2pYjSMYeTuT/DBnDzE3LomYUC4oBk0KdfdceFX5Cfu2CCp2XbNZ3VfC3f1q3bJbOQbYnYTqWi9+Tw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=klJpoF9Q; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="klJpoF9Q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CAB641F000E9; Tue, 23 Jun 2026 13:50:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782222650; bh=T5QITE/W9PWMiSnQSEb25byqiClC1qtSsa9UGS2bkgQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=klJpoF9QJYIA992HykJ0OHqFE91SA7biVpawmOh8gndjtVq7FZdJveGAcnCGHXUHj XgkbacMTO7qIJdOLo/u931CynW2Pc2BtI1FMbV38yBzieKRsKzF5XM7URKF5Wlv8Xw 6FC7kyHOHcPB08NQCw9XPqwO93g9WbW8LS2unGpp1+61s7YSWoYzuMDnR4RoUv/EiT 2TQ3nCXc9p7xXlqeI2wZwMPi8QOnZ0SpyYhvGDhZMG5Jmb1a31Ots9mosJM9t3jXs2 GKsifzR5QNGIH9TGjjoxBQpajoAezIJYyz3ucIKrc1mcxzEEWKlndlRLvEU7H0Jes/ 4GoB86z0yPrbw== 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 1wc1Wa-0000000FIy8-2nQI; Tue, 23 Jun 2026 13:50:48 +0000 Date: Tue, 23 Jun 2026 14:50:48 +0100 Message-ID: <86se6dqsav.wl-maz@kernel.org> From: Marc Zyngier To: Will Deacon Cc: Bradley Morgan , Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm In-Reply-To: References: <20260621213155.6019-1-include@grrlz.net> <86zf0nq8ki.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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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: will@kernel.org, include@grrlz.net, oupton@kernel.org, tabba@google.com, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@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 On Tue, 23 Jun 2026 14:41:20 +0100, Will Deacon wrote: > > On Mon, Jun 22, 2026 at 09:32:29AM +0100, Marc Zyngier wrote: > > On Sun, 21 Jun 2026 22:31:55 +0100, > > Bradley Morgan wrote: > > > > > > Protected guest faults charge long term pins to the VM's mm. Teardown > > > can run later from file release, where current->mm may be unrelated. > > > > > > Drop the charge from kvm->mm instead. > > > > > > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()") > > > Signed-off-by: Bradley Morgan > > > --- > > > arch/arm64/kvm/pkvm.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c > > > index 053e4f733e4b..428723b1b0f5 100644 > > > --- a/arch/arm64/kvm/pkvm.c > > > +++ b/arch/arm64/kvm/pkvm.c > > > @@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64 > > > page = pfn_to_page(mapping->pfn); > > > WARN_ON_ONCE(mapping->nr_pages != 1); > > > unpin_user_pages_dirty_lock(&page, 1, true); > > > - account_locked_vm(current->mm, 1, false); > > > + account_locked_vm(kvm->mm, 1, false); > > > pkvm_mapping_remove(mapping, &pgt->pkvm_mappings); > > > kfree(mapping); > > > } > > > > Seems correct to me, as the final mmdrop(kvm->mm) occurs after S2 > > teardown. > > > > Will, what do you think? > > Thanks, this looks correct to me. > > While I was thinking about it, I also started looking at the use of > 'current->mm' in kvm_arch_prepare_memory_region() in case that should > also be 'kvm->mm'. However, I then realised that I don't really grok > that code at all because it does a bunch of checking on the VMAs with > mmap_read_lock(current->mm) held, but then that lock is dropped > immediately after doing the checks so I'm not really sure what they > are protected against. Presumably, the address space could be modified > as soon as the lock is dropped? > > But it's hot, so I'm probably missing something here. I think this is just trying to catch a few obvious issues, such as dirty logging on device memory, but that only works for well behaved userspace that is making "a honest mistake". For the more trying ones, we end-up doing the same checks again at fault time anyway. M. -- Without deviation from the norm, progress is not possible.