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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53570EE7FE8 for ; Fri, 8 Sep 2023 12:34:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B21056B00BC; Fri, 8 Sep 2023 08:34:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA8FD6B00BE; Fri, 8 Sep 2023 08:34:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FBCD6B00BF; Fri, 8 Sep 2023 08:34:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 77AF56B00BC for ; Fri, 8 Sep 2023 08:34:28 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4CE82B365C for ; Fri, 8 Sep 2023 12:34:28 +0000 (UTC) X-FDA: 81213373416.03.1AA8502 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf17.hostedemail.com (Postfix) with ESMTP id 346A44000D for ; Fri, 8 Sep 2023 12:34:25 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=HVMwezQl; dmarc=none; spf=pass (imf17.hostedemail.com: domain of alexghiti@rivosinc.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=alexghiti@rivosinc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694176466; a=rsa-sha256; cv=none; b=rET3qZP9A7m7jfZWGma4lUrgxcOx0kABfaZfa7rE5duRk0zpaw+Enx4+3XdA31BQXyVgBM RpIkkEk8ATDK1z8QJfNVm3EmR4Sr9R7bHlXdeNHv90XDFSJx1Ps6GGBloLdYFxBIXXBf6A YLBogkR+/zqmMlUn7/ml3NPWaiTEzoA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=HVMwezQl; dmarc=none; spf=pass (imf17.hostedemail.com: domain of alexghiti@rivosinc.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=alexghiti@rivosinc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694176466; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nlMlO8FealBj+/rrG/AUzU2UA5CdlNvzxR7wkSDN7Ow=; b=KBlG+D/VxmZeEDFcCW1DsoG1cPEAmifCzxI1jJRhH0EZncIHnLKD554W7uK1c8v+q+6Odf QMP5s0XkNWvo8B4oVBiSZ0oBx7jgNtA5cZLC4n4JKiynpOQ4UTurIbnQW5nzkNAZKf9XJf Bk6IzcVfO5mwKb2AqgbtU5aNxyspMug= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-401d24f1f27so22523995e9.1 for ; Fri, 08 Sep 2023 05:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1694176464; x=1694781264; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nlMlO8FealBj+/rrG/AUzU2UA5CdlNvzxR7wkSDN7Ow=; b=HVMwezQlPKvAAmhBbRKbmHMJ2N7BZDFpbivcgk70BicwDS9xyZGX5FeEENQiJvFtlF bO+mQq1OPl0AZ9RLX9SIzvXmcgRB3jvyl7xexoM66OehEvJ+G8vAAhtbuVEHNcAuIhpZ nPWjscvBJsGqW6fz6ZzdlR+o3YwqCjBpMWPhSSizE7mz7Lxn7RElztV687AOp31G9NGr pGOiTk10doaX18Tn+GTGG7ELX6aBPAHlc0ZimO9RGS9mDCzXZ2ZLTt8aZibaM9FqtM0e AetLn+7cq6I/KFJHOzJSODyPGm1Z777Jkthqc7f5KbEuY0mQG5xH8HUXNK75YgL+H+GD //zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694176464; x=1694781264; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nlMlO8FealBj+/rrG/AUzU2UA5CdlNvzxR7wkSDN7Ow=; b=TC2+vG3cjVqsLlO373x/Robb+dBJlVR9DuvacfEMEEtDYhQVKt0ieeox7WU7JvehuM rpoxV0QV0NRDg3Zdc4G2/fkHQIpycq7EinUBsQ/6J77I2wleA01ZT/um3b6tMRcadcHn Mlqp5iPnuPRDks9//JzYBXD3DPdW3qQfi9Mmyd0Plg9zyreLOLeYeTA3FdwWDmn0Oy9i 5f4AvdX1KF1JbmHI1bGSeCX1GhJO5NyGV2cIWNiZAt1z6qKuuPgT1Z/Oil1bsN2qkMtW Lu+FneHfNFdaL1I7SLP+JniL516WPt+KTnWwT4ACaZI2yGKOF7wCHMaHyUBLKquqazdG k6Qg== X-Gm-Message-State: AOJu0YySSW3L0w333MhQnhe4uNMHnxcwTBw3e6AtzTb0Fyzmmitn+x1n 0Xf1YkfDTlCJlysahN7zKc0YNkuKTp9IBki9XyEjwg== X-Google-Smtp-Source: AGHT+IFouy2jXUNwy6DNVaskl+A4XjlMLTTSBWXz6mwTmjOEmm+0FPBkaPo/JXFsNJuqUEU9OtqmCQTG4i1XKpihnfo= X-Received: by 2002:a05:6000:180b:b0:319:6caa:ada2 with SMTP id m11-20020a056000180b00b003196caaada2mr1742878wrh.47.1694176464379; Fri, 08 Sep 2023 05:34:24 -0700 (PDT) MIME-Version: 1.0 References: <20230801085402.1168351-1-alexghiti@rivosinc.com> <20230801085402.1168351-5-alexghiti@rivosinc.com> In-Reply-To: From: Alexandre Ghiti Date: Fri, 8 Sep 2023 14:34:13 +0200 Message-ID: Subject: Re: [PATCH v3 4/4] riscv: Improve flush_tlb_kernel_range() To: "Lad, Prabhakar" Cc: Geert Uytterhoeven , Will Deacon , "Aneesh Kumar K . V" , Andrew Morton , Nick Piggin , Peter Zijlstra , Mayuresh Chitale , Vincent Chen , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Andrew Jones Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 346A44000D X-Stat-Signature: h3tespojequgrkphx9b7cjn57boq4t3c X-HE-Tag: 1694176465-44153 X-HE-Meta: U2FsdGVkX1/vByH972m0OXLxSvrOI0CK6Tmg45symAlPb+Mn2XCGz2iutzXaBakpGtAqgy/5PWwsdmYXkwRfpKYLBj3l6f4nAnazxy8Mtcxv+eHdjStvIZyaIHJ1eK5c6kqHGl3+hSPbUt0MySIyAWB9OiEA2q7+MKU2bP8DM0Uf/g+Hc4Yeodq1cEGF+yDI6tdolb71wMAypTpSl/4TDgWzOR4b5f1cS5W95S7qJxL7u3r4jOOFij/5pUUrjBiml4uscAuR7paFBV7YuhfT5EnyfnpjXPnP38M0ZPu8wbgsE5MXVVZ+7j2IgbyZo+qRUvKkznW/b+wbdEpwDa7cOWRs1PGW1NIM8DSUSTi/8Vs1Ra2luqZB5Z90v/VJG9K2ghl/uRQxrSJH4BBFVrvft8AUt3xKBnDMebAQ1boe4R9ojPCYBQ2njC9oHS/ESHVUBnQKHX9x8r8UQ6f85wpZTNfJkYtjKthdICnY7bS/F1ChKcgevmuHrElC1qfAwjPnDY78C9PHf/XnjgCdQ9g7IdR2WAXSGvEZ15Gld0+fRmLBJeZsbGzfMv17QWMPLCXRQcUEc2nRKkV/W+efGyHRqqKSztiwlMs4NVwvBnjaOrCR83bC86poOWz1Pl8v9JHlJbr3lfwh37AH6cx2z6VCSzC3/PaY1u1SqdbUQiioEz1v7nyVPbm+iLZq8aXrPGReFTiypym6kSnj0Z6OZiMXgyEHe5BGS0Ww8OPSq3V8m/93MbdCVPg4N1kPcxKEeVYW8n68n0W6s2pYilVanAN3zIL0B9YPuE4JcCyb1FCdtIIRjfcmqenqomcHma7RD4l5LXqnIdCzYH1fx6hRsgLVLUvR7L18OGmBCllS7Obg+m4ZBRCZ91J/w0iS8Seuw2KOvguuVxCyhvNKzHobKHxlE4wPyW2DCUfmpvNtivTgnEwwq0btOyyRT1rTGfPS/Jo6PPOJTj6TJSWp1shC1M3 ITMMmfWE 8a7lkHxyF7fcVfnbAgg19Hdld51elUSuckiFbH5ZEURI3kgjXTJ0SBTfKaQ6lC5HrwUfcM0oVnO+IjiqnbflNriDNVAUeThTpJZyDwQTwv7BZW1RcMWmxIZzZwhDMgVKEy3MSuChjpcj9Pa5EqQ1rCwPe7EjxdbUMWCuIax36ngQkXm/o1vHp92PD0V1n4rh/KxF8eeCwfB2wp90jcEtZB5Xuo+0xmvXQGHWj6G4n5t+KYVVgJiXZQrj4HpQNP8cxhE54QazdsPUTfqcnnaQuWa2AYfjkUcZaqQEtN3xtrKA2Jq0iqLR/Nm+wWwItTa/tLApFQzjA04MEzJ/4UP2xlWDOCSSX+2Cxt6L7sTrCsibnAhwcIf9yEtlkh7mUCnC2Yy3mEBmRs4LMqb31g8N1VMpGEZ1+HzGpLaySEZSP4Zpkr0FrUbC+IKaXTYM6qezgESexzSXMf5rij01WHmFgZb5E6bfMzIhpbnYaGVlVcOAxOD/foekRLs5o47HrT866yLVmdQmeVEI1F3KH4CGxGF+L7NZICh/Cq/lwYgQ6wCuCyk+PQLSBa4qjKy1a8SbQcb5V X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Prabhakar, On Thu, Sep 7, 2023 at 12:50=E2=80=AFPM Lad, Prabhakar wrote: > > Hi Alexandre, > > On Thu, Sep 7, 2023 at 10:06=E2=80=AFAM Alexandre Ghiti wrote: > > > > Hi Prabhakar, > > > > On Wed, Sep 6, 2023 at 3:55=E2=80=AFPM Lad, Prabhakar > > wrote: > > > > > > Hi Alexandre, > > > > > > On Wed, Sep 6, 2023 at 1:43=E2=80=AFPM Alexandre Ghiti wrote: > > > > > > > > On Wed, Sep 6, 2023 at 2:24=E2=80=AFPM Lad, Prabhakar > > > > wrote: > > > > > > > > > > Hi Alexandre, > > > > > > > > > > On Wed, Sep 6, 2023 at 1:18=E2=80=AFPM Alexandre Ghiti wrote: > > > > > > > > > > > > On Wed, Sep 6, 2023 at 2:09=E2=80=AFPM Lad, Prabhakar > > > > > > wrote: > > > > > > > > > > > > > > Hi Alexandre, > > > > > > > > > > > > > > On Wed, Sep 6, 2023 at 1:01=E2=80=AFPM Alexandre Ghiti wrote: > > > > > > > > > > > > > > > > Hi Prabhakar, > > > > > > > > > > > > > > > > On Wed, Sep 6, 2023 at 1:49=E2=80=AFPM Lad, Prabhakar > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Alexandre, > > > > > > > > > > > > > > > > > > On Tue, Aug 1, 2023 at 9:58=E2=80=AFAM Alexandre Ghiti wrote: > > > > > > > > > > > > > > > > > > > > This function used to simply flush the whole tlb of all= harts, be more > > > > > > > > > > subtile and try to only flush the range. > > > > > > > > > > > > > > > > > > > > The problem is that we can only use PAGE_SIZE as stride= since we don't know > > > > > > > > > > the size of the underlying mapping and then this functi= on will be improved > > > > > > > > > > only if the size of the region to flush is < threshold = * PAGE_SIZE. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Alexandre Ghiti > > > > > > > > > > Reviewed-by: Andrew Jones > > > > > > > > > > --- > > > > > > > > > > arch/riscv/include/asm/tlbflush.h | 11 +++++----- > > > > > > > > > > arch/riscv/mm/tlbflush.c | 34 +++++++++++++++= ++++++++-------- > > > > > > > > > > 2 files changed, 31 insertions(+), 14 deletions(-) > > > > > > > > > > > > > > > > > > > After applying this patch, I am seeing module load issues= on RZ/Five > > > > > > > > > (complete log [0]). I am testing defconfig + [1] (rz/five= related > > > > > > > > > configs). > > > > > > > > > > > > > > > > > > Any pointers on what could be an issue here? > > > > > > > > > > > > > > > > Can you give me the exact version of the kernel you use? Th= e trap > > > > > > > > addresses are vmalloc addresses, and a fix for those landed= very late > > > > > > > > in the release cycle. > > > > > > > > > > > > > > > I am using next-20230906, Ive pushed a branch [1] for you to = have a look. > > > > > > > > > > > > > > [0] https://github.com/prabhakarlad/linux/tree/rzfive-debug > > > > > > > > > > > > Great, thanks, I had to get rid of this possibility :) > > > > > > > > > > > > As-is, I have no idea, can you try to "bisect" the problem? I m= ean > > > > > > which patch in the series leads to those traps? > > > > > > > > > > > Oops sorry for not mentioning earlier, this is the offending patc= h > > > > > which leads to the issues seen on rz/five. > > > > > > > > Ok, so at least I found the following problem, but I don't see how > > > > that could fix your issue: can you give a try anyway? I keep lookin= g > > > > into this, thanks > > > > > > > > diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c > > > > index df2a0838c3a1..b5692bc6c76a 100644 > > > > --- a/arch/riscv/mm/tlbflush.c > > > > +++ b/arch/riscv/mm/tlbflush.c > > > > @@ -239,7 +239,7 @@ void flush_tlb_range(struct vm_area_struct *vma= , > > > > unsigned long start, > > > > > > > > void flush_tlb_kernel_range(unsigned long start, unsigned long end= ) > > > > { > > > > - __flush_tlb_range(NULL, start, end, PAGE_SIZE); > > > > + __flush_tlb_range(NULL, start, end - start, PAGE_SIZE); > > > > } > > > > > > > I am able to reproduce the issue with the above change too. > > > > I can't reproduce the problem on my Unmatched or Qemu, so it is not > > easy to debug. But I took another look at your traces and something is > > weird to me. In the following trace (and there is another one), the > > trap is taken at 0xffffffff015ca034, which is the beginning of > > rz_ssi_probe(): that's a page fault, so no translation was found (or > > an invalid one is cached). > > > > [ 16.586527] Unable to handle kernel paging request at virtual > > address ffffffff015ca034 > > [ 16.594750] Oops [#3] > > ... > > [ 16.622000] epc : rz_ssi_probe+0x0/0x52a [snd_soc_rz_ssi] > > ... > > [ 16.708697] status: 0000000200000120 badaddr: ffffffff015ca034 > > cause: 000000000000000c > > [ 16.716580] [] rz_ssi_probe+0x0/0x52a > > [snd_soc_rz_ssi] > > ... > > > > But then here we are able to read the code at this same address: > > [ 16.821620] Code: 0109 6597 0000 8593 5f65 7097 7f34 80e7 7aa0 b7a9 > > (7139) f822 > > > > So that looks like a "transient" error. Do you know if you uarch > > caches invalid TLB entries? If you don't know, I have just written > > some piece of code to determine if it does, let me know. > > > No I dont, can you please share the details so that I can pass on the > information to you. > > > Do those errors always happen? > > > Yes they do. > I still can't reproduce those errors, I built different configs including yours, insmod/rmmod a few modules but still can't reproduce that. I'm having a hard time understanding how the correct mapping magically appears in the trap handler. We finally removed this patchset from 6.6... You can give the following patch a try to determine if your uarch caches invalid TLB entries, but honestly, I'm not sure if that would help (but it will test my patch :)). The output can be seen in dmesg "uarch caches invalid entries:". If the trap addresses are constant, I would try to breakpoint on flush_tlb_kernel_range() on those addresses and see what happens: maybe that's an alignment issue or something else, maybe that's not even called before the trap...etc. More info are welcome :) Thanks! diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 80af436c04ac..8f863b251898 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -58,6 +58,8 @@ bool pgtable_l5_enabled =3D IS_ENABLED(CONFIG_64BIT) && !IS_ENABLED(CONFIG_XIP_KER EXPORT_SYMBOL(pgtable_l4_enabled); EXPORT_SYMBOL(pgtable_l5_enabled); +bool tlb_caching_invalid_entries; + phys_addr_t phys_ram_base __ro_after_init; EXPORT_SYMBOL(phys_ram_base); @@ -752,6 +754,18 @@ static void __init disable_pgtable_l4(void) satp_mode =3D SATP_MODE_39; } +static void __init enable_pgtable_l5(void) +{ + pgtable_l5_enabled =3D true; + satp_mode =3D SATP_MODE_57; +} + +static void __init enable_pgtable_l4(void) +{ + pgtable_l4_enabled =3D true; + satp_mode =3D SATP_MODE_48; +} + static int __init print_no4lvl(char *p) { pr_info("Disabled 4-level and 5-level paging"); @@ -828,6 +842,113 @@ static __init void set_satp_mode(uintptr_t dtb_pa) memset(early_pud, 0, PAGE_SIZE); memset(early_pmd, 0, PAGE_SIZE); } + +/* Determine at runtime if the uarch caches invalid TLB entries */ +static __init void set_tlb_caching_invalid_entries(void) +{ +#define NR_RETRIES_CACHING_INVALID_ENTRIES 50 + uintptr_t set_tlb_caching_invalid_entries_pmd =3D ((unsigned long)set_tlb_caching_invalid_entries) & PMD_MASK; + // TODO the test_addr as defined below could go into another pud... + uintptr_t test_addr =3D set_tlb_caching_invalid_entries_pmd + 2 * PMD_SIZE; + pmd_t valid_pmd; + u64 satp; + int i =3D 0; + + /* To ease the page table creation */ + // TODO use variable instead, like in the clean, nop stap_mode too + disable_pgtable_l5(); + disable_pgtable_l4(); + + /* Establish a mapping for set_tlb_caching_invalid_entries() in sv3= 9 */ + create_pgd_mapping(early_pg_dir, + set_tlb_caching_invalid_entries_pmd, + (uintptr_t)early_pmd, + PGDIR_SIZE, PAGE_TABLE); + + /* Handle the case where set_tlb_caching_invalid_entries straddles 2 PMDs */ + create_pmd_mapping(early_pmd, + set_tlb_caching_invalid_entries_pmd, + set_tlb_caching_invalid_entries_pmd, + PMD_SIZE, PAGE_KERNEL_EXEC); + create_pmd_mapping(early_pmd, + set_tlb_caching_invalid_entries_pmd + PMD_SIZE, + set_tlb_caching_invalid_entries_pmd + PMD_SIZE, + PMD_SIZE, PAGE_KERNEL_EXEC); + + /* Establish an invalid mapping */ + create_pmd_mapping(early_pmd, test_addr, 0, PMD_SIZE, __pgprot(0)); + + /* Precompute the valid pmd here because the mapping for pfn_pmd() won't exist */ + valid_pmd =3D pfn_pmd(PFN_DOWN(set_tlb_caching_invalid_entries_pmd), PAGE_KERNEL); + + local_flush_tlb_all(); + satp =3D PFN_DOWN((uintptr_t)&early_pg_dir) | SATP_MODE_39; + csr_write(CSR_SATP, satp); + + /* + * Set stvec to after the trapping access, access this invalid mapp= ing + * and legitimately trap + */ + // TODO: Should I save the previous stvec? +#define ASM_STR(x) __ASM_STR(x) + asm volatile( + "la a0, 1f \n" + "csrw " ASM_STR(CSR_TVEC) ", a0 \n" + "ld a0, 0(%0) \n" + ".align 2 \n" + "1: \n" + : + : "r" (test_addr) + : "a0" + ); + + /* Now establish a valid mapping to check if the invalid one is cached */ + early_pmd[pmd_index(test_addr)] =3D valid_pmd; + + /* + * Access the valid mapping multiple times: indeed, we can't use + * sfence.vma as a barrier to make sure the cpu did not reorder acc= esses + * so we may trap even if the uarch does not cache invalid entries.= By + * trying a few times, we make sure that those uarchs will see the = right + * mapping at some point. + */ + + i =3D NR_RETRIES_CACHING_INVALID_ENTRIES; + +#define ASM_STR(x) __ASM_STR(x) + asm_volatile_goto( + "la a0, 1f \n" + "csrw " ASM_STR(CSR_TVEC) ", a0 \n" + ".align 2 \n" + "1: \n" + "addi %0, %0, -1 \n" + "blt %0, zero, %l[caching_invalid_entries] \n" + "ld a0, 0(%1) \n" + : + : "r" (i), "r" (test_addr) + : "a0" + : caching_invalid_entries + ); + + csr_write(CSR_SATP, 0ULL); + local_flush_tlb_all(); + + /* If we don't trap, the uarch does not cache invalid entries! */ + tlb_caching_invalid_entries =3D false; + goto clean; + +caching_invalid_entries: + csr_write(CSR_SATP, 0ULL); + local_flush_tlb_all(); + + tlb_caching_invalid_entries =3D true; +clean: + memset(early_pg_dir, 0, PAGE_SIZE); + memset(early_pmd, 0, PAGE_SIZE); + + enable_pgtable_l4(); + enable_pgtable_l5(); +} #endif /* @@ -1040,6 +1161,7 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa) #endif #if defined(CONFIG_64BIT) && !defined(CONFIG_XIP_KERNEL) + set_tlb_caching_invalid_entries(); set_satp_mode(dtb_pa); #endif @@ -1290,6 +1412,9 @@ static void __init setup_vm_final(void) local_flush_tlb_all(); pt_ops_set_late(); + + pr_info("uarch caches invalid entries: %s", + tlb_caching_invalid_entries ? "yes": "no"); } #else asmlinkage void __init setup_vm(uintptr_t dtb_pa) > Cheers, > Prabhakar