From: Cheng Chao <cs.os.kernel@gmail.com>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: paul.walmsley@sifive.com, palmer@dabbelt.com,
aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org
Subject: Re: [PATCH] riscv: mm: check the SV39 rule
Date: Mon, 7 Oct 2024 17:44:32 +0800 [thread overview]
Message-ID: <CA+1SViAjeqYL8obCDxC=vvaKOadf9A0WSfCfF771NKAiN5bZDQ@mail.gmail.com> (raw)
In-Reply-To: <42d4b2cd-5c22-45bf-86b7-0ae128b2fc63@ghiti.fr>
Hi Alexandre,
Thanks for reviewing this patch. I don't reply on time due to the
National Day :)
On Mon, Sep 30, 2024 at 3:46 PM Alexandre Ghiti <alex@ghiti.fr> wrote:
>
> Hi Cheng,
>
> On 28/09/2024 17:52, Cheng Chao wrote:
> > SV39 rule: the address of bits[63..39] should be the same as bit[38],
> > it is easy to violate if configure PAGE_OFFSET too small.
> > for instance, PAGE_OFFSET=0xffffffc0_0000_0000,
>
>
> Out of curiosity, why do you try to modify the current memory layout?
It's a long story. I'm working on kernel-5.10, and the default
PAGE_OFFSET 0xffffffe0_0000_0000 can only map the 128G physical
address,
and we need to map more than 128G in the real world.
After I changed PAGE_OFFSET to a smaller value which can map a more
physical address.
the kernel panic(page fault) when earlycon printk, the cause is 0xf,
badaddr is 0xffffffbx_xxxx_xxxx.
It took me several days to debug this panic, at the beginning, I
considered MMU doesn't work for earlycon, so I traced the pgd/pmd/pte,
all are correct before page fault.
Occasionally, I found the SV39 rule: the address of bits[63..39]
should be the same as bit[38], the address 0xffffffbx_xxxx_xxxx
violates the rule.
The root cause is that the kernel doesn't sense the SV39 rule, so when
I adjust the PAGE_OFFSET, the FIXADDR_START will adjust too without
any check.
when accessing the [FIXADDR, FIXADDR + PMD_SIZE] , the kernel will
have a page fault.
>
>
> > the FIXADDR_START will be the 0xfffffffb0_xxxx_xxxx,
> > bit[39] == 0'b1, bit[38] == 0'b0, when access the FIXADDR,
> > which cause the page fault.
> > It's difficult to debug, check it when compile is necessary.
> >
> > Signed-off-by: Cheng Chao <cs.os.kernel@gmail.com>
> > ---
> > arch/riscv/mm/init.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > index bfa2dea95354..a5fb3fc2b2db 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -1387,6 +1387,12 @@ static void __init arch_reserve_crashkernel(void)
> >
> > void __init paging_init(void)
> > {
> > +#ifdef CONFIG_64BIT
> > + BUILD_BUG_ON_MSG((VA_BITS == VA_BITS_SV39) &&
>
>
> VA_BITS is determined at runtime, either by setting "noXlvl" on the
> kernel command line or by probing the HW capabilities, so the above
> can't be determined at build time, or am I missing something?
>
you are right,
in case of CONFIG_XIP_KERNEL=y, VA_BITS will be VA_BITS_SV39, this
patch works.
other cases, disable_pgtable_l4 will enable SATP_MODE_39, we also
check SV39 rule here?
@@ -763,6 +763,11 @@ static void __init disable_pgtable_l4(void)
pgtable_l4_enabled = false;
kernel_map.page_offset = PAGE_OFFSET_L3;
satp_mode = SATP_MODE_39;
+
+ if ((VA_BITS == VA_BITS_SV39) &&
+ (((FIXADDR_START & BIT(39)) >> 39)
+ != ((FIXADDR_START & BIT(38)) >> 38)))
+ panic("violate SV39 rule: bits[63..39] should be same
as bit[38]\n");
}
>
> > + (((FIXADDR_START & BIT(39)) >> 39)
> > + != ((FIXADDR_START & BIT(38)) >> 38)),
> > + "violate SV39 rule: bits[63..39] should be same as bit[38]");
> > +#endif
> > setup_bootmem();
> > setup_vm_final();
> >
>
>
> Thanks,
>
> Alex
>
Thanks,
Cheng Chao
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-10-07 9:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-28 15:52 [PATCH] riscv: mm: check the SV39 rule Cheng Chao
2024-09-30 7:46 ` Alexandre Ghiti
2024-10-07 9:44 ` Cheng Chao [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-09-28 15:56 Cheng Chao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+1SViAjeqYL8obCDxC=vvaKOadf9A0WSfCfF771NKAiN5bZDQ@mail.gmail.com' \
--to=cs.os.kernel@gmail.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).