[PATCH] riscv: Remove support for XIP kernel

[Charles Mirabile]

Hi Nam—

On Thu, Mar 26, 2026 at 12:45 PM Nam Cao <namcao at linutronix.de> wrote:
>
> Charles Mirabile <cmirabil at redhat.com> writes:
> > Chiming in as another voice interested in not scrapping XIP. I think
> > RISC-V is an interesting position as an ISA of being able to support
> > both desktop/server class high performance designs, but also low cost
> > embedded applications. The ability to run linux in M-Mode without an
> > MMU, and even XIP directly from storage within one code base just by
> > changing configuration options is fantastic and positions linux to be
> > the obvious kernel of choice for both kinds of RISC-V implementations.
> >
> > That being said, it is clear that these use-cases are not being tested
> > or maintained. The addition of runtime constant support for RISC-V also
> > broke no-mmu which I fixed in:
> > 8d90d9872edae ("riscv: fix runtime constant support for nommu kernels")
> > and clearly is also XIP which I did not test at the time and did not
> > realize. I have a patch to essentially just disable the runtime constants
> > logic on RISC-V when CONFIG_XIP_KERNEL is enabled here that should fix it:
> > https://lore.kernel.org/lkml/20260320155843.1848180-1-cmirabil@redhat.com
>
> FWIW, the patch looks correct to me. I can test it if we decided to keep XIP.

I actually discovered that it does not compile when I tested it with
CONFIG_XIP=y (really I should have at least compile tested before
sending the mail, sorry for that). The gist of the issue is that
simply not defining the macros is insufficient, instead I need to
include the asm-generic header with the replacement no-op definitions
of them when using CONFIG_XIP.

I have a fixed version that I am happy to share which was enough to
get non smp qemu virt to boot, but to your point about no one actually
testing XIP on real hardware, I found at least two more issues when I
tried to do that.

The first is just related to SMP generically and reproduces on qemu
virt with -smp >1 (though I discovered it when trying to use qemu
sifive_u with the appropriate -smp 5 to match the physical hardware)
basically the secondary cores do not come up because of two incorrect
/ unneeded `XIP_FIXUP_OFFSET` invocations in secondary_start_sbi.

Then I found another issue in `setup_bootmem` with
`CONFIG_SPARSEMEM_VMEMMAP` where it tries to modify
`vmemmap_start_pfn` but without doing a fixup so I added a wrapper
macro for it with `XIP_FIXUP` (analogous to those for the other C
variables in arch/riscv/mm/init.c).

This only caused a noticeable issue on the physical sifive unleashed
board, so I am thinking that maybe trying to write to the read-only
flash region for XIP in qemu is just discarded without causing a trap
and not initializing that variable is not fatal whereas it does trap
on the real thing.

I was holding off and planning on sending all three as a patchset once
I was able to get it fully working on both qemu virt and qemu sifive_u
and also the real unleashed board, but there seems to be at least one
more bug happening on the real hardware that has been hard to debug
(crashing my gdb/jtag setup while trying to single step lol).

>
> > That being said, In truth I have not actually built or used an XIP linux
> > kernel on RISC-V, so I am not sure I can volunteer to test or maintain it
> > at this moment, but I am planning on experimenting with M-Mode noMMU XIP
> > linux on the sifive hifive unleashed board with the hope of creating a
> > kernel that can act as a linuxboot payload and essentially replace the
> > firmware of the device. With the fix I proposed, perhaps it is tenable to
> > not remove XIP at this time and go back to the status quo? I understand
> > that it is just kicking the can down the road until the next time someone
> > makes a change that breaks XIP and no one notices if no one is testing,
> > but maybe we can have a conversation about how we could improve the
> > situation in the meantime and have an actual plan to catch that before
> > such a breaking patch makes it to mainline next time.
>
> I'm not sure if we should be keeping it for the hope that maybe a use
> case will appear in the future. We can always revert it back when we do
> need it in the future. But for now, it is being maintenance burden with
> no benefit.
>
> I presume your experiment does not require the latest kernel, and you can
> use the older versions which still support XIP?

It is true, though I would like it to continue to be possible
upstream. When I wrote this I didn't realize that XIP is currently not
compatible with M-mode linux. I think that would be a really useful
combination that might actually make XIP something that people
use/test since both m-mode / nommu linux and xip are more common in
embedded usecases.

I was hoping to develop patches for that functionality too and prove
that it works on real hardware. But in order to do that I would need
to figure out m-mode linux on unleashed/qemu sifive_u (almost
certainly possible, but I haven't really tested it) and also XIP linux
on unleased/sifive_u (which as I said is close, but with at least one
more issue) and then combine them simultaneously (unclear how hard
lol).

I would want to port this to other platforms as well in the future,
but the unleashed is just the ideal first platform because of how well
documented / open it is and the fact that there is a corresponding
qemu sifive_u machine to simulate.

>
> Nam
>

Best—Charlie