No SBI way for supervisor to change SXLEN

[robotman2412]

It appears that the SBI specification doesn't currently support changing SXLEN. Of course, not all cores can do this, but I think it would potentially be valuable on cores that can.

I think we could add an SBI call of some kind to ask for this type of switch in either direction (32 to 64 or 64 to 32). It would allow 32-bit operating systems to try to still load, even if the SBI initially started them as 64-bit.

Now I acknowledge that while I'm currently making RISC-V CPUs, I'm not as good at this stuff yet as some others may be. Maybe it's impractical to add this, in which case I'm interested to know why.

[cmuellner]

Is there a particular use case that you have in mind?
I would expect that SXLEN is only set during bootup before S-mode SW is started.

I see the following issues with switching SXLEN at run-time:

• What if your $pc is beyond 2^32 when you make the SBI call? What would be the return address?
• SXLEN is not reset to a defined value in case of exceptions, so S-mode exception handler prologues would not even know which part of the registers has to be saved.

[robotman2412]

What I imagine is a bootloader running in S-mode (Limine, some kernel with kexec, etc.) would want to load an OS but the OS is 32-bit.
This would of course require running the OS in a 32-bit mode, but the S-mode bootloader has no way of doing it without emulating the SBI itself for the rest of the OS' lifetime.

I think it could be acceptable to have a "please re-start here in this XLEN" mode (i.e. all of the S-mode software is restarted that way).
If it's just the synchronous change idea, then it's up to the OS to disable its interrupts and manage the switch gracefully.