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 4E5E7C6FD18 for ; Thu, 30 Mar 2023 01:20:16 +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=qHwAk3Pe1R2JH0P4Hip6akNRFvSM2HPiSuQY3B1O5os=; b=HwviTne2D7wK6S M/l8xl/8BDl8UNyNcIk/Y6AYSIRGpYlunEZ6+RzQSsxkSwcHmNih6Mv1Ez1PjQgcVI7bOTUXnM7ws lj42DFNEQtJ5SmFosF1MM6SZdQbWQMeEkVW7and9nvlbfRHyitW/3SZffGgDPKyUD7lJazlEaHNTK Sx351IKFb9PDKB8hoYIBeeh+2GGNU3T27hl6HIyhKna0RSPHXBNTJWTNKbyrYRZ1XThwQm4bSvnZp VzL1Jw0O1+9K75rS62v9/DZsSmvWvuMfNTfZLi7sqh6+kIH65N3YWsy7I7bXlI/Dcn3awMltxTCnr sYYRvKwJm+1XG4SgAPlg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1phgwh-002Fbd-2D; Thu, 30 Mar 2023 01:19:19 +0000 Received: from out-11.mta1.migadu.com ([95.215.58.11]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1phgwe-002Fai-14 for linux-arm-kernel@lists.infradead.org; Thu, 30 Mar 2023 01:19:18 +0000 Date: Thu, 30 Mar 2023 01:19:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1680139152; 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=ieJMdM29DRBiOqszQV7TS65QczUNcFjEDp7KMm1vo3M=; b=K99/mO6ZmX+9Z0SOnOzW1yNj0BHgL3UOGUt5LDv4XF9H4nY2Cg0HyI0qsjQUQNx7YLeIe0 uom4b/i4ad0aQ5i458f25KJCmhDQSZwecGkcQn5VkL+En/wHNQ+m4NVLwnEMwFh8yvPosG I4QEkthBz0FE0FQ9g1HCfE7t7CgQvbk= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Raghavendra Rao Ananta Cc: Oliver Upton , Marc Zyngier , Ricardo Koller , Reiji Watanabe , James Morse , Alexandru Elisei , Suzuki K Poulose , Will Deacon , Paolo Bonzini , Catalin Marinas , Jing Zhang , Colton Lewis , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH v2 2/7] KVM: arm64: Add FEAT_TLBIRANGE support Message-ID: References: <20230206172340.2639971-1-rananta@google.com> <20230206172340.2639971-3-rananta@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230206172340.2639971-3-rananta@google.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230329_181916_786994_D67FBD40 X-CRM114-Status: GOOD ( 20.02 ) 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, Feb 06, 2023 at 05:23:35PM +0000, Raghavendra Rao Ananta wrote: > Define a generic function __kvm_tlb_flush_range() to > invalidate the TLBs over a range of addresses. The > implementation accepts 'op' as a generic TLBI operation. > Upcoming patches will use this to implement IPA based > TLB invalidations (ipas2e1is). > > If the system doesn't support FEAT_TLBIRANGE, the > implementation falls back to flushing the pages one by one > for the range supplied. > > Signed-off-by: Raghavendra Rao Ananta > --- > arch/arm64/include/asm/kvm_asm.h | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h > index 43c3bc0f9544d..995ff048e8851 100644 > --- a/arch/arm64/include/asm/kvm_asm.h > +++ b/arch/arm64/include/asm/kvm_asm.h > @@ -221,6 +221,24 @@ DECLARE_KVM_NVHE_SYM(__per_cpu_end); > DECLARE_KVM_HYP_SYM(__bp_harden_hyp_vecs); > #define __bp_harden_hyp_vecs CHOOSE_HYP_SYM(__bp_harden_hyp_vecs) > > +#define __kvm_tlb_flush_range(op, mmu, start, end, level, tlb_level) do { \ > + unsigned long pages, stride; \ > + \ > + stride = kvm_granule_size(level); \ Hmm... There's a rather subtle and annoying complication here that I don't believe is handled. Similar to what I said in the last spin of the series, there is no guarantee that a range of IPAs is mapped at the exact same level throughout. Dirty logging and memslots that aren't hugepage aligned could lead to a mix of mapping levels being used within a range of the IPA space. > + start = round_down(start, stride); \ > + end = round_up(end, stride); \ > + pages = (end - start) >> PAGE_SHIFT; \ > + \ > + if ((!system_supports_tlb_range() && \ > + (end - start) >= (MAX_TLBI_OPS * stride)) || \ Doesn't checking for TLBIRANGE above eliminate the need to test against MAX_TLBI_OPS? > + pages >= MAX_TLBI_RANGE_PAGES) { \ > + __kvm_tlb_flush_vmid(mmu); \ > + break; \ > + } \ > + \ > + __flush_tlb_range_op(op, start, pages, stride, 0, tlb_level, false); \ > +} while (0) > + > extern void __kvm_flush_vm_context(void); > extern void __kvm_flush_cpu_context(struct kvm_s2_mmu *mmu); > extern void __kvm_tlb_flush_vmid_ipa(struct kvm_s2_mmu *mmu, phys_addr_t ipa, > -- > 2.39.1.519.gcb327c4b5f-goog > > -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel