On 2/13/26 2:11 PM, Jan Beulich wrote:
On 13.02.2026 13:54, Oleksii Kurochko wrote:
On 2/12/26 5:39 PM, Jan Beulich wrote:
On 12.02.2026 17:21, Oleksii Kurochko wrote:
--- a/xen/include/public/arch-riscv.h
+++ b/xen/include/public/arch-riscv.h
@@ -50,6 +50,14 @@ typedef uint64_t xen_ulong_t;
#if defined(__XEN__) || defined(__XEN_TOOLS__)
+#define GUEST_RAM_BANKS 1
+
+#define GUEST_RAM0_BASE xen_mk_ullong(0x80000000) /* 2GB of low RAM @ 2GB */
+#define GUEST_RAM0_SIZE xen_mk_ullong(0x80000000)
+
+#define GUEST_RAM_BANK_BASES { GUEST_RAM0_BASE }
+#define GUEST_RAM_BANK_SIZES { GUEST_RAM0_SIZE }
Hmm, does RISC-V really want to go with compile-time constants here?
It is needed for allocate_memory() for guest domains, so it is expected
to be compile-time constant with the current code of common dom0less
approach.
It represents the start of RAM address for DomU and the maximum RAM size
(the actual size will be calculated based on what is mentioned in DomU node
in dts) and then will be used to generate memory node for DomU (GUEST_RAM0_BASE
as RAM start address and min(GUEST_RAM0_SIZE, dts->domU->memory->size) as a
RAM size).
And
if so, why would guests be limited to just 2 Gb?
It is enough for guest domain I am using in dom0less mode.
And what others may want to use RISC-V for once it actually becomes usable
isn't relevant? As you start adding things to the public headers, you will
need to understand that you can't change easily what once was put there.
Everything there is part of the ABI, and the ABI needs to remain stable
(within certain limits).
Considering this ...
That may more efficiently
be RV32 guests then, with perhaps just an RV32 hypervisor.
I didn't get this point. Could you please explain differently what do you
mean?
If all you want are 2Gb guests, why would such guests be 64-bit? And with
(iirc) RV32 permitting more than 4Gb (via PPN being 22 bits wide), perhaps
even a 32-bit hypervisor would suffice?
... now I can agree that Xen should permit bigger amount of RAM. At least,
(2^34-1) should be allowed for RV32 and so for RV64 so it could be used
like a base for both of them. As RV64 allows (2^56 - 1) it makes sense
to add another bank to cover range from 2^34 to (2^56 -1) for RV64 (and ifdef
this second bank for RV64).
Would it be better?
~ Oleksii
