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 29538C27C52 for ; Wed, 5 Jun 2024 07:57:00 +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=dc/eis0SOh4tHqys33CbxkBawBW7HKuHw9I67JdW8Gw=; b=KxuJXlY957gs70 sKvWe87fZGAX/JY1Cl9/aBpxXWjYjNThoUEHmxlq5t0dKMdsNgsVXhqD0DR4cHRLvPMz9b2Pr0sfi 9yyZZkBmwT+SpyiAjbVjXZGarQQM1FbuCViG7m/k7ZsnVEaF/9Ot/VzCociNGo9YO86SPVEhEfSwl ysMoJEnBBlMPp7txF1RFA+JdEmJLciqB5nTr7A/dBJkzCY1bpyk7RoNLSzt4ExmkyNubbq6oANHIk 8U+gS6jxJzplz6czr6IGQJBPWfuocO/DdxNejD8kOVfVq+UqQFMbnkoGaMCML63jDVp+LtubgF/k2 xmPlmrJkoH0ML+BYWv/g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sElVn-000000055Gh-0hY2; Wed, 05 Jun 2024 07:56:47 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sElVj-000000055FM-37KG for linux-arm-kernel@lists.infradead.org; Wed, 05 Jun 2024 07:56:45 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 4D3E96125A; Wed, 5 Jun 2024 07:56:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F12BFC3277B; Wed, 5 Jun 2024 07:56:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717574200; bh=SrMwiri/fv5VbxUe1nm98++rbHYD+JdlXdKw90ZRXqU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BKNsysE+JPMhfwHiglgXg1P2pg4cgyhhcDpjTikJsgvI9MwiyJgEQIQjP+HtbSfW5 XzprlmBIbicEHCa86FUXRCLVu0cDxYF5Gj7r/lK1MwjgXTMRLhBEMwd1bsJ2Syh2rC iqa1BZyczGT7fZZfeJtMfEpWqRfQAzG5MsOyLXGwYniVhGizK9iJxw3kUKH9nLf/pJ 3VRkAXpnOV5qqdIy0B+nbfMSc1Y8iRROqnf54oA4sH1AcQ2W0NcJ8fFNC9TbESmxY6 neLnaRSCAS1TX0Gv2vf8Hl6XDscT4c7TI/Wb4CJSBSREZBd+vIa8IqIsWjiDtQ/Pnf wNeJ113H4IAQQ== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] 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 1sElVd-000q4X-Sq; Wed, 05 Jun 2024 08:56:38 +0100 Date: Wed, 05 Jun 2024 08:56:36 +0100 Message-ID: <87ed9b3jrf.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 , Joey Gouly , Alexandru Elisei , Christoffer Dall , Ganapatrao Kulkarni Subject: Re: [PATCH v2 12/16] KVM: arm64: nv: Tag shadow S2 entries with guest's leaf S2 level In-Reply-To: References: <20240529145628.3272630-1-maz@kernel.org> <20240529145628.3272630-13-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/28.2 (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.104.136.29 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, joey.gouly@arm.com, alexandru.elisei@arm.com, christoffer.dall@arm.com, gankulkarni@os.amperecomputing.com 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-20240605_005643_890442_4441EB3C X-CRM114-Status: GOOD ( 39.18 ) 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 Mon, 03 Jun 2024 19:05:23 +0100, Oliver Upton wrote: > > On Wed, May 29, 2024 at 03:56:24PM +0100, Marc Zyngier wrote: > > Populate bits [56:55] of the leaf entry with the level provided > > by the guest's S2 translation. This will allow us to better scope > > the invalidation by remembering the mapping size. > > > > Of course, this assume that the guest will issue an invalidation > > with an address that falls into the same leaf. If the guest doesn't, > > we'll over-invalidate. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/kvm_nested.h | 8 ++++++++ > > arch/arm64/kvm/mmu.c | 17 +++++++++++++++-- > > 2 files changed, 23 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h > > index fcb0de3a93fe..971dbe533730 100644 > > --- a/arch/arm64/include/asm/kvm_nested.h > > +++ b/arch/arm64/include/asm/kvm_nested.h > > @@ -5,6 +5,7 @@ > > #include > > #include > > #include > > +#include > > > > static inline bool vcpu_has_nv(const struct kvm_vcpu *vcpu) > > { > > @@ -195,4 +196,11 @@ static inline bool kvm_auth_eretax(struct kvm_vcpu *vcpu, u64 *elr) > > } > > #endif > > > > +#define KVM_NV_GUEST_MAP_SZ (KVM_PGTABLE_PROT_SW1 | KVM_PGTABLE_PROT_SW0) > > + > > +static inline u64 kvm_encode_nested_level(struct kvm_s2_trans *trans) > > +{ > > + return FIELD_PREP(KVM_NV_GUEST_MAP_SZ, trans->level); > > +} > > + > > It might be nice to keep all of the software fields for (in)valid in > a central place so we can add some documentation. I fear this is going > to get rather complicated as more pieces of pKVM land upstream and we > find new and fun ways to cram data into stage-2. I had that at some point, but it then became clear that pKVM and NV were pretty much incompatible in their current respective incarnation. To get them to play together, you'd need to reinvent the NV wheel solely at EL2, something that nobody is looking forward to. What I'm aiming at with this digression is that although they use the same bits, NV and pKVM are never using them at the same time. If we shove them at the same location, we make it less clear what is used when (hence pKVM keeping its toys in mem_protect.h). But maybe you had a scheme in mind that would avoid this situation? > > > #endif /* __ARM64_KVM_NESTED_H */ > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > > index 4ed93a384255..f3a8ec70bd29 100644 > > --- a/arch/arm64/kvm/mmu.c > > +++ b/arch/arm64/kvm/mmu.c > > @@ -1598,11 +1598,17 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, > > * Potentially reduce shadow S2 permissions to match the guest's own > > * S2. For exec faults, we'd only reach this point if the guest > > * actually allowed it (see kvm_s2_handle_perm_fault). > > + * > > + * Also encode the level of the nested translation in the SW bits of > > + * the PTE/PMD/PUD. This will be retrived on TLB invalidation from > > + * the guest. > > typo: retrieved > > Also, it might be helpful to add some color here to indicate the encoded > TTL is used to represent the span of a single virtual TLB entry, > providing scope to the TLBI by address. > > Before I actually read what was going on, I thought the TTL in the PTE > was used for matching invalidation scopes that have a valid TTL. How about this: /* * Also encode the level of the original translation in the SW bits of * the leaf entry as a proxy for the span of that translation. This will * be retrieved on TLB invalidation from the guest and used to limit * the invalidation scope if a TTL hint or a range isn't provided. */ 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