M mode is forced by the architecture, and SBI is essential to making that
work. SBI has grown like cancer, to the point that SMP startup now requires
SBI, replacing the old lottery system. We discussed M-mode-free SoC in
2014, but in 2025, I can see that's never going to happen.
So you have to have SBI. And the kernel and SBI share data, so it would be
nice to give them a compatible address range.
Consider kmapaddr. With the address space at the top, here is today's
version:
static void*
kmapaddr(uintptr pa)
{
if(pa < (uintptr)-KZERO)
return (void*)(pa + KZERO);
if(pa < (VDRAM - KZERO) || pa >= (VDRAM - KZERO) + (KMAPEND - KMAP))
panic("kmapaddr: pa=%#p pc=%#p", pa, getcallerpc(&pa));
return (void*)(pa + KMAP - (VDRAM - KZERO));
}
// Note: this panics. I don't know why just yet.
0-based KVA version:
static void*
kmapaddr(uintptr pa)
{
if (pa < 1<<62) return (void *)pa;
panic("kmapaddr: pa=%#p pc=%#p", pa, getcallerpc(&pa));
return nil;
}
That second version I can understand; that first version makes my head
hurt. Further, what is KZERO? Well, the answer is, it depends on whether
your RISC-V is sv39, sv48, or sv57. It's painful.
Looking at things a bit more, UVA already starts at 2M. As a test, I'm
going to build the kernel with KZERO = 0, start UVA at 1<<31 and see if I
get any distance,
I'm tired of all this math. (uintptr)-KZERO? bah.
ron
On Wed, Jan 7, 2026 at 12:12 PM Richard Miller <[email protected]> wrote:
> [email protected]:
> > you can't avoid M mode on riscv, ever. There are several trap cases that
> > will drop you in to M mode.
>
> I thought avoiding M mode was forced on you by the SBI implementation
> (firmware), which intercepts M mode traps and delegates them to S mode
> (if it feels like it). That's my recollection from working with the
> Polarfire Icicle, but it's a few years back. Or are you designing for
> a bare metal platform with no SBI?
>
> Are there any riscv implementations on the market which allow kernel
> and user mode to run with different XLEN, and thus enable a 64-bit
> kernel to host 32-bit processes? If so, I think that implies that
> you would want user address space to start at (or near) zero.
>
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-Ma7e1202fce4910d209f48b65
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
