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 A03A3CD1288 for ; Wed, 3 Apr 2024 08:58:21 +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=wPSMLEiwf7WtAemMA9DzOHuj7bRTqVu/1Pk/AWq/F1o=; b=fk4+J8aXkgF7uW nZxKPy6dZZecOFKyytVeVV4uxxHl/tJ5J0acZYE9kZHDB0c+LssfqWoxyn9sNTpa9K5vm6/JXomeq Lpv4zoIEQjAzWp4yqmHi81ZxcRQTubJ2rEX4EZZXFGogO0y6IVJdENAq4JluOOmBj/mb8xNRhS9Kk HL5hz/6OQ8Y16lH56X3X71d9J9RkX5yhgsgdIwyB2PFqOtJ4V66qoiGGHzU/wCFex93Py10uFJ8YN Vpqz9e7kP0TogmCvy2XdoUCjifqM1Zq0SfLJivuQuivw8IofPE//eS+ri7YBoJRRZFTFY1WgIrO3c zwOfASEo96fA4Keu/CiQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrwRe-0000000F4Tq-2RBA; Wed, 03 Apr 2024 08:58:10 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rrwRa-0000000F4T4-3FWi for linux-arm-kernel@lists.infradead.org; Wed, 03 Apr 2024 08:58:08 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 54145CE210D; Wed, 3 Apr 2024 08:58:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8A705C433F1; Wed, 3 Apr 2024 08:58:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712134683; bh=ZAIxO5z+o29M+kH6syBeb8pWBi2QGdZ/xqTOqqX+69U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TvVHdHIt0Vhh680xjUkrJGcZ9+qyaXdxeojcZXMFfJCmFx3lGzuDSq9rWE5VZawKM uD+TVKWb3DclzG26NMCTWVOGykIvRq8UHILyGtStHGecB1HVQbSJbexWIm3+o5dSw2 nPiOLC8oBQN0FTnISTDECrkG29rPNw67SGKACNiruTvXZq9E5EHBo2hXxrJhLoZWHq i0/ZDcCDWvF7NEek92UTlzGthkrM/73Le2kwTOb9a7g3fXLUdmzJaQPrO+w9S94rq9 6e3yVGH+xHog2tMmxRHuZ0+sXcAnwaoIie1yTqAgzm+cEMkD5t94tlZ4r6/E32e+Jm 4FL/Cy0ZqUcdg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1rrwRU-00112V-Mi; Wed, 03 Apr 2024 09:58:00 +0100 Date: Wed, 03 Apr 2024 09:58:00 +0100 Message-ID: <86edbmu8kn.wl-maz@kernel.org> From: Marc Zyngier To: Gavin Shan Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, akpm@linux-foundation.org, apopple@nvidia.com, mark.rutland@arm.com, ryan.roberts@arm.com, rananta@google.com, yangyicong@hisilicon.com, v-songbaohua@oppo.com, yezhenyu2@huawei.com, yihyu@redhat.com, shan.gavin@gmail.com Subject: Re: [PATCH] arm64: tlb: Fix TLBI RANGE operand In-Reply-To: <20240403064929.1438475-1-gshan@redhat.com> References: <20240403064929.1438475-1-gshan@redhat.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/29.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: gshan@redhat.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, akpm@linux-foundation.org, apopple@nvidia.com, mark.rutland@arm.com, ryan.roberts@arm.com, rananta@google.com, yangyicong@hisilicon.com, v-songbaohua@oppo.com, yezhenyu2@huawei.com, yihyu@redhat.com, shan.gavin@gmail.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-20240403_015807_261006_AB885452 X-CRM114-Status: GOOD ( 34.48 ) 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, 03 Apr 2024 07:49:29 +0100, Gavin Shan wrote: > > KVM/arm64 relies on TLBI RANGE feature to flush TLBs when the dirty > bitmap is collected by VMM and the corresponding PTEs need to be > write-protected again. Unfortunately, the operand passed to the TLBI > RANGE instruction isn't correctly sorted out by commit d1d3aa98b1d4 > ("arm64: tlb: Use the TLBI RANGE feature in arm64"). It leads to > crash on the destination VM after live migration because some of the > dirty pages are missed. > > For example, I have a VM where 8GB memory is assigned, starting from > 0x40000000 (1GB). Note that the host has 4KB as the base page size. > All TLBs for VM can be covered by one TLBI RANGE operation. However, > I receives 0xffff708000040000 as the operand, which is wrong and the > correct one should be 0x00007f8000040000. From the wrong operand, we > have 3 and 1 for SCALE (bits[45:44) and NUM (bits943:39], only 1GB > instead of 8GB memory is covered. > > Fix the macro __TLBI_RANGE_NUM() so that the correct NUM and TLBI > RANGE operand are provided. > > Fixes: d1d3aa98b1d4 ("arm64: tlb: Use the TLBI RANGE feature in arm64") > Cc: stable@kernel.org # v5.10+ > Reported-by: Yihuang Yu > Signed-off-by: Gavin Shan > --- > arch/arm64/include/asm/tlbflush.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h > index 3b0e8248e1a4..07c4fb4b82b4 100644 > --- a/arch/arm64/include/asm/tlbflush.h > +++ b/arch/arm64/include/asm/tlbflush.h > @@ -166,7 +166,7 @@ static inline unsigned long get_trans_granule(void) > */ > #define TLBI_RANGE_MASK GENMASK_ULL(4, 0) > #define __TLBI_RANGE_NUM(pages, scale) \ > - ((((pages) >> (5 * (scale) + 1)) & TLBI_RANGE_MASK) - 1) > + ((((pages) >> (5 * (scale) + 1)) - 1) & TLBI_RANGE_MASK) > > /* > * TLB Invalidation This looks pretty wrong, by the very definition of the comment that's just above: /* * Generate 'num' values from -1 to 30 with -1 rejected by the * __flush_tlb_range() loop below. */ With your change, num can't ever be negative, and that breaks __flush_tlb_range_op(): num = __TLBI_RANGE_NUM(pages, scale); \ if (num >= 0) { \ addr = __TLBI_VADDR_RANGE(start >> shift, asid, \ scale, num, tlb_level); \ __tlbi(r##op, addr); \ if (tlbi_user) \ __tlbi_user(r##op, addr); \ start += __TLBI_RANGE_PAGES(num, scale) << PAGE_SHIFT; \ pages -= __TLBI_RANGE_PAGES(num, scale); \ } \ scale--; \ We'll then shove whatever value we've found in the TLBI operation, leading to unknown results instead of properly adjusting the scale to issue a smaller invalidation. I think the problem is that you are triggering NUM=31 and SCALE=3, which the current code cannot handle as per the comment above __flush_tlb_range_op() (we can't do NUM=30 and SCALE=4, obviously). Can you try the untested patch below? Thanks, M. diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h index 3b0e8248e1a4..b71a1cece802 100644 --- a/arch/arm64/include/asm/tlbflush.h +++ b/arch/arm64/include/asm/tlbflush.h @@ -379,10 +379,6 @@ static inline void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch) * 3. If there is 1 page remaining, flush it through non-range operations. Range * operations can only span an even number of pages. We save this for last to * ensure 64KB start alignment is maintained for the LPA2 case. - * - * Note that certain ranges can be represented by either num = 31 and - * scale or num = 0 and scale + 1. The loop below favours the latter - * since num is limited to 30 by the __TLBI_RANGE_NUM() macro. */ #define __flush_tlb_range_op(op, start, pages, stride, \ asid, tlb_level, tlbi_user, lpa2) \ @@ -407,6 +403,7 @@ do { \ \ num = __TLBI_RANGE_NUM(pages, scale); \ if (num >= 0) { \ + num += 1; \ addr = __TLBI_VADDR_RANGE(start >> shift, asid, \ scale, num, tlb_level); \ __tlbi(r##op, addr); \ -- 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