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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 20.03.2026 10:58, Oleksii Kurochko wrote:
> On 3/19/26 8:58 AM, Jan Beulich wrote:
>> On 17.03.2026 13:49, Oleksii Kurochko wrote:
>>> On 2/13/26 2:11 PM, Jan Beulich wrote:
>>>>>>> +#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 }
>>> (cut)
>>>
>>>> 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?
>>> Btw, shouldn't we look at VPN width?
>>>
>>> My understanding is that we should take GUEST_RAM0_BASE as sgfn address
>>> and then map it to mfn's page (allocated by alloc_domheap_pages())? And then
>>> repeat this process until we won't map GUEST_RAM0_SIZE.
>>>
>>> In this case for RV32 VPN (which is GFN in the current context) is 32-bit
>>> wide as RV32 supports only Sv32, what is 2^32 - 1, what is almost 4gb.
>> ??? (IOW - I fear I'm confused enough by the question that I don't know how
>> to respond.)
> 
> You mentioned above that:
>    "... And with (iirc) RV32 permitting more than 4Gb (via PPN being 22 bits 
> wide) ..."
> 
> I wanted to clarify why you use PPN here in the context of GUEST_RAM0_BASE 
> definition.
> (and maybe I just misinterpreted incorrectly your original message)
> GUEST_RAM0_BASE is the address at which the guest believes RAM starts in its 
> physical
> address space, i.e. it is a GPA, which is then translated to an MPA.
> 
>  From the MMU's perspective, the GPA looks like:
>    VPN[1] | VPN[0] | page_offset   (in Sv32x4 mode)
> 
> In Sv32x4, the GPA is 34 bits wide (or 22 bits wide in terms of GFNs), and 
> the MPA is
> also 32 bits wide (or 22 bits wide in terms of PPN).

You mentioning Sv32x4 may point at part of the problem: For the guest physical
memory layout (and hence size), paging and hence virtual addresses don't matter
at all. What matters is what the guest can put in the page table entries it
writes. Addresses there are represented as PPNs, aren't they? Hence my use of
that acronym.

> The distinction is not significant in Sv32x4, since PPN width equals VPN 
> width, but
> in other modes VPN < PPN (in terms of bit width).
> So when we want to run a guest in Sv39x4 mode and want to give the guest the 
> full
> Sv39x4 address space, setting GUEST_RAM0_SIZE to the maximum possible value 
> for
> Sv39x4, shouldn't we look at the VPN width rather than the PPN width?

No, why? The guest can arrange to map more than 2^39 bytes. Not all at the same
time, sure, but by suitable switching page tables (or merely entries) around.

Jan

> In other words, GUEST_RAM0_SIZE should be (2^41 - 1) rather than (2^56 - 1)
> for Sv39x4.
> 
> ~ Oleksii
>