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 1D594C25B75 for ; Mon, 3 Jun 2024 18:05:50 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bgv+120c3MMrf2K9N035KA/V6S5+MkZAF3WSYaddOdM=; b=ZtIrqVNrO2OvVh jwYdpi7+52epoPK0+eO7wabh7AEl8qdxBgsia1StiJ0h8wDebFAZJayjwb0vUeIyFhVqz3bOknq46 6GLuMu8WLoBEr00Nd3Pc7xiyJrna0XQrFyLYtkV0jj/ywRMxP3WeVWCmHrtLz9xKIMdN2eD62CyLe OjVRxAPoEn7UuPjLe0GbZlSOhQlMBen5vLMbbRaremlhsY6c1Hg91w/LlK2U9QtHiGw0J8RZlIvyz dWBIuKpJudumrYN6d0gJpOr9aLmOAv7M0q2SLXPeZN/8Kv4NXiTIgOq9BOM/ClzTFaAzcypuvwvnp 94QTbZJSO7zrRMsGJjRw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEC3u-0000000Ha1M-4BjW; Mon, 03 Jun 2024 18:05:39 +0000 Received: from out-181.mta1.migadu.com ([95.215.58.181]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEC3s-0000000Ha0t-0Sfb for linux-arm-kernel@lists.infradead.org; Mon, 03 Jun 2024 18:05:37 +0000 X-Envelope-To: maz@kernel.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1717437930; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v8c1jmco2IK+JdoaMwMA27Do8TVfUJeGMj6T9ZSs0To=; b=OuMZ2KIMa3bNCwB6yjNMGJ8lhcLV4DZDNpss0MFB5B2M1SLFglh0cBqtBFgAP9R5OEFGG+ rkbNpuKMRWR2k5w2b268ZdlpBYesyvY30/Gf8dmfxmHb+GVi+T32KrlqXFzyLkg3Tb5heB lpumwqe0k1+tlfxHHrf7hI/+JxFZ8u0= X-Envelope-To: kvmarm@lists.linux.dev X-Envelope-To: kvm@vger.kernel.org X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: james.morse@arm.com X-Envelope-To: suzuki.poulose@arm.com X-Envelope-To: yuzenghui@huawei.com X-Envelope-To: joey.gouly@arm.com X-Envelope-To: alexandru.elisei@arm.com X-Envelope-To: christoffer.dall@arm.com X-Envelope-To: gankulkarni@os.amperecomputing.com Date: Mon, 3 Jun 2024 18:05:23 +0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Marc Zyngier 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 Message-ID: References: <20240529145628.3272630-1-maz@kernel.org> <20240529145628.3272630-13-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20240529145628.3272630-13-maz@kernel.org> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240603_110536_528518_285087B9 X-CRM114-Status: GOOD ( 24.81 ) 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 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. > #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. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel