Re: [PATCH] riscv: Remove support for XIP kernel

[Nam Cao]

Charles Mirabile <cmirabil@xxxxxxxxxx> 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@xxxxxxxxxx

FWIW, the patch looks correct to me. I can test it if we decided to keep XIP.

> 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?

Nam