Re: [PATCH v1 6/6] xen/riscv: enable DOMAIN_BUILD_HELPERS

[Oleksii Kurochko <oleksii.kurochko@gmail.com>]

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