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 266AE15E5A2; Wed, 5 Jun 2024 07:56:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717574200; cv=none; b=hZl+49KvgqFldwIhMNUHp3fUGblS/UwzJjfUSbFh1eKC6CE3Trsufj0jTJYX6diG+l/XxYR+jg6DlYexwwFVYBLcoCN113jG72EvWTLhDo3Hx6XvAyPIBSurbvBDNn5eYg+7GtG+6EWnmqQG7haKN7kVIQif9lHjcAIkNAtYQL4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717574200; c=relaxed/simple; bh=SrMwiri/fv5VbxUe1nm98++rbHYD+JdlXdKw90ZRXqU=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=szwTpBlEcvn8shVam0LTTLUrxbs6VNDmGvfG2aKSK2LfEgTxJShYDIPrxNXQT+NZ5KeFlzCakkb2Av8thr4oDCknNXlQg+i1qbxr/NWNtxfhzDnC4IoHSlkoiafmZXeLCMrmMjz61FS7OREq21Iyl+4HHO0DTe1caV2MbQlVaAE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BKNsysE+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BKNsysE+" 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) Precedence: bulk X-Mailing-List: kvm@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.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 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.