Add support for 32-bit RISC-V

[josecm]

This PR introduces support for RV32. Because the way the instruction set is written the difference is not much when comparing to RV64. The main areas of modification are:

• modifying assembly instructions that used 64-bit load/store directly by the LOAD/STORE macro which translates to either ld/st or lw/sw depending on if we are targetting RV64 or RV32, respectively;
• support for the sv32 translation mode. This also requires adapting the boot code where the bootstrap page-tables are built manually.
• adapt CSR access to CSRs that have a H variant (e.g., henvcfg, henvcfgh), and other small related issues;
• fix small issues that assumed 64-bit literals.

The PR also includes support for qemu-system-riscv32 virt machine, which is essentially a wrapper over the 64-bit variant.

The main issue with this port is related to the fact that we are required to map all available physical memory to perform page-table walks. Because the address space is so small (4GiB), this might not be possible as for RV64 we simply identity map all physical memory and assume these addresses won't collide with the high virtual addresses used by the hypervisor. This is not the case and we might not be able to map all physical addresses, which already happens for qemu-riscv32-virt if we configure it with memory larger than 1 GiB, since it starts memory at 0x80000000. We might need a dynamic mechanism similar to Linux's "highmem" in the future. I only think this is worth it if a real platform that requires it becomes available. Also, the main purpose of supporting RV32 is to target future MMU-less systems.

Test guest:

• Baremetal app
• Linux

Depends on #115

[josecm]

I have booted 32-bit Linux over Bao too.

I think this is ready to be fully reviewed @ninolomata @DavidMCerdeira @danielRep

[danielRep]

I still couldn't finish my review , but as a first note we still need a PR on bao-demos to support 32-bit RISC-V as a means to test this PR.

[danielRep]

While I don't see a huge problem on using compilation macros macros (RV32 and RV64), wouldn't be more cleaner to separate rv32 and rv64 profiles on different arch folders as we do for aarch32 and aarch64?

[josecm]

A branch for bao-demos featuring demos targetting qemu-riscv32-virt is available at https://github.com/josecm/bao-demos/tree/feat/rv32. I'll create a PR for that demo once this PR is accepted.

[josecm]

While I don't see a huge problem on using compilation macros macros (RV32 and RV64), wouldn't be more cleaner to separate rv32 and rv64 profiles on different arch folders as we do for aarch32 and aarch64?

The difference between rv32 and rv64 is not as stark as from aarch32 to aarch64, so it does not seem necessary to introduce both architectures separately, only a few of those RV32/RV64 macros and a wrapper around csr access so that rv32 can access "64-bit" csrs is enough and avoids a lot of code duplication and indirection.

[danielRep]

While I don't see a huge problem on using compilation macros macros (RV32 and RV64), wouldn't be more cleaner to separate rv32 and rv64 profiles on different arch folders as we do for aarch32 and aarch64?

The difference between rv32 and rv64 is not as stark as from aarch32 to aarch64, so it does not seem necessary to introduce both architectures separately, only a few of those RV32/RV64 macros and a wrapper around csr access so that rv32 can access "64-bit" csrs is enough and avoids a lot of code duplication and indirection.

Seems reasonable. Ok, looks good to me.

[danielRep]

A branch for bao-demos featuring demos targetting qemu-riscv32-virt is available at https://github.com/josecm/bao-demos/tree/feat/rv32. I'll create a PR for that demo once this PR is accepted.

Good! I'll further test if everything is working correctly on that PR then.