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 529B1C79F85 for ; Sun, 6 Sep 2026 15:44:52 +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=JihxV/V344AJDLHX61A3DZDDBIEXJEfRoj7Xx/kGeoA=; b=dVF2ov7oz2am94ybkVaXFt37Qu EFAoc/2PLJm5h1++N6Eg3HAkepXCZrnVPSAdgRRjiHJ65er+WcAvtWLJ8SNoR04VntWLFHFUXFlXL gMW9x0xeLDFghC81XbEHc4nYbwFp+KG5QKGMIYGC0RYJIRMDun30DX4tI4+3QYsih5R6/v6cmm+KU ScuaHuJPoKB8cOIIpOdT1fsSh4dTYE+4ktIX5zYl5AVgVd1jGvFB4GzXk65wi8Q0CX6H7CdQ7N/AS n60eQvWMKYjN8O2kBYo6MeJXFqE0h4K1SQTEhIuch2N21wNceA6P0HXegz3ESUq/vpnMnCwvToyKQ z2edlBBQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x3F2m-000000059RJ-21nX; Sun, 06 Sep 2026 15:44:32 +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 1x3F2l-000000059R9-1704 for linux-arm-kernel@lists.infradead.org; Sun, 06 Sep 2026 15:44:31 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 4975E600AA; Sun, 6 Sep 2026 15:44:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F03F51F00A3A; Sun, 6 Sep 2026 15:44:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788709470; bh=JihxV/V344AJDLHX61A3DZDDBIEXJEfRoj7Xx/kGeoA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=OdcqP/vwKiEzFm+QZyJJK4nD4Y59+eRxZF7uUQoqPxGWGMfhe9LA/4m4hvOnhcYWv ZKlLKuIg4ZfOCKjylrSMukWDLdwCBZ1BPg5D+GXWRfgj1cGTwL0EslCRaKkTLwD1yO 91HGkZ5B6cilZFdwhlSa03qxcYSOuWglTIO7KmRkzxSP0ffhBYVC/AnS1LRvo29jnI UMeiVqJ13nr2mezhZLj3l5VPzmXCSCZJULI02myHUiaW/ArcHckOvfy68DSMyfPVhj wRa+c+gXxLteyWsPsr9oo2Jae7tZ+pN/3Yvo7vLrMwqgL6Vx5I2aukb8/fnTij8GwR PwKqtAFFB+2EQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-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 1x3F2h-00000005Quk-1bM5; Sun, 06 Sep 2026 15:44:27 +0000 Date: Sun, 06 Sep 2026 16:47:02 +0100 Message-ID: <87mrtu4c21.wl-maz@kernel.org> From: Marc Zyngier To: Wei-Lin Chang Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Lorenzo Stoakes , Itaru Kitayama Subject: Re: [PATCH v5 2/6] KVM: arm64: nv: Introduce guest stage-2 tracking structures In-Reply-To: <20260810205038.118843-3-weilin.chang@arm.com> References: <20260810205038.118843-1-weilin.chang@arm.com> <20260810205038.118843-3-weilin.chang@arm.com> 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: weilin.chang@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, 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, will@kernel.org, ljs@kernel.org, itaru.kitayama@fujitsu.com 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 Mon, 10 Aug 2026 21:50:34 +0100, Wei-Lin Chang wrote: > > In order to avoid unmapping all shadow stage-2 mappings when KVM > receives a MMU notifier unmap call, we have to keep track of the > canonical IPA -> nested IPA relationship of the shadow mappings > created. This essentially means tracking the guest's stage-2. > > To do this, represent each mapping by struct kvm_guest_s2_mapping. It > stores the mapping's canonical IPA range and the nested IPA range using > two interval tree nodes. Both nodes will be inserted into their > respective interval trees called guest_s2_mappings. The canonical IPA > ranges will be stored in the tree within the canonical MMU, and the > nested IPA ranges will be stored in the corresponding nested MMU's tree. > > For example: > > struct kvm_guest_s2_mapping mapping1, mapping2; > > ---------------------> mapping2.canonical > | mapping1.canonical > | ^ (both stored in canonical mmu's tree) > | | > --*****-----------------------*****----------- CIPA > \\\\\ ||||| mapping1.nested_mmu > \\\\\ \\\\\ | > \\\\\ \\\\\ v > ------\\\\\---------------------*****--------- NIPA #1 (nested mmu #1) > \\\\\ | > \\\\\ -> mapping1.nested > \\\\\ (stored in nested mmu #1's tree) > \\\\\ > -----------*****------------------------------ NIPA #2 (nested mmu #2) > | ^ > -> mapping2.nested | > (stored in nested mmu #2's tree) mapping2.nested_mmu > > Using the trees we can look up nodes in either of the IPA spaces, and > for each node, find the corresponding range in the other IPA space from > the other node in the enclosing kvm_guest_s2_mapping. > > Define kvm_guest_s2_mapping and the interval tree here. Guest stage-2 > mapping tracking will come in subsequent patches. > > Signed-off-by: Wei-Lin Chang > --- > arch/arm64/include/asm/kvm_host.h | 17 +++++++++++++++++ > arch/arm64/kvm/mmu.c | 30 ++++++++++++++++++++++++++++++ > arch/arm64/kvm/nested.c | 1 + > 3 files changed, 48 insertions(+) > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index bae2c4f92ef5..0695c4ef93f1 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -150,6 +151,16 @@ struct kvm_vmid { > atomic64_t id; > }; > > +/* > + * Record of a guest stage-2 mapping, storing canonical and nested IPA > + * ranges. Both ranges have the same size. > + */ > +struct kvm_guest_s2_mapping { > + struct interval_tree_node canonical; > + struct interval_tree_node nested; > + struct kvm_s2_mmu *nested_mmu; > +}; > + I'm trying hard to find a way to reduce the size of this structure, because this is IMO the only real problem with this approach. Obviously, the only thing we could kill is this nested_mmu field, as everything else is used by the interval trees. I can see two ugly ways to do that: - either we iterate over all shadow MMUs to find the corresponding 'nested' node: really costly if we have a lot of mappings and/or a lot of shadow MMUs - or we steal bits from the interval_tree_node to encode extra information. One realisation is that all addresses are PAGE_SIZE aligned, meaning that we have at least 12 bits that are always 0. We could, for example, encode an index in the bottom bits of the nested.start field. Probably easy enough, but may require some careful masking (and the addition of an index in the s2_mmu structure). The result would be significant, as we could then use a 96 byte slab, which means the cost of a 1GB @4k granularity could fall to 24MB. I don't think this is an immediate blocker for this series, but I'd like to at least have a plan... Thoughts? M. -- Jazz isn't dead. It just smells funny.