Re: [PATCH v2 10/11] xen/riscv: add definition of guest RAM banks

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.03.2026 17:29, Oleksii Kurochko wrote:
> The dom0less solution uses defined RAM banks as compile-time constants,
> so introduce macros to describe guest RAM banks.
> 
> The reason for 2 banks is that there is typically always a use case for
> low memory under 4 GB, but the bank under 4 GB ends up being small because
> there are other things under 4 GB it can conflict with (interrupt
> controller, PCI BARs, etc.).

Fixed layouts like the one you suggest come with (potentially severe)
downsides. For example, what if more than 2Gb of MMIO space are needed
for non-64-bit BARs? Further, assuming that the space 4G...8G is what
you expect 64-bit BARs to be put into, what if there's a device with a
4G BAR? It'll eat up that entire space, requiring everything else to
fit in the 2G you reserve below 4G.

> So a second bank is added above that MMIO
> region (starting at 8 GiB) to provide the remaining RAM; the gap between
> the two banks also exercises code paths handling discontiguous memory.
> For Sv32 guests (34-bit GPA, 16 GiB addressable), bank0 provides 2 GB
> (2–4 GB) and the first 8 GB of bank1 (8–16 GB) is accessible.
> 
> Extended regions are useful for RISC-V: they could be used to provide a
> "space" for Linux to map grant mappings.
> 
> Despite the fact that for every guest MMU mode the GPA could be up
> to 56 bits wide (except Sv32 whose GPA is 34 bits), the combined size
> of both banks is limited to 1018 GB as it is more than enough for most
> use cases.

Okay, more memory can be made available by (later) adding an optional
3rd bank.

> --- a/xen/include/public/arch-riscv.h
> +++ b/xen/include/public/arch-riscv.h
> @@ -50,6 +50,22 @@ typedef uint64_t xen_ulong_t;
>  
>  #if defined(__XEN__) || defined(__XEN_TOOLS__)
>  
> +#define GUEST_RAM_BANKS   2
> +
> +/*
> + * The way to find the extended regions (to be exposed to the guest as unused
> + * address space) relies on the fact that the regions reserved for the RAM
> + * below are big enough to also accommodate such regions.
> + */
> +#define GUEST_RAM0_BASE   xen_mk_ullong(0x80000000) /* 2GB of low RAM @ 2GB 
> */
> +#define GUEST_RAM0_SIZE   xen_mk_ullong(0x80000000)

Connecting this with my comment on the earlier patch regarding kernel, initrd,
and DTB fitting in bank 0: How's that going to work with a huge kernel and/or
initrd (I expect DTBs can't grow very large)?

> +#define GUEST_RAM1_BASE   xen_mk_ullong(0x0200000000) /* 1016 GB of RAM @ 
> 8GB */
> +#define GUEST_RAM1_SIZE   xen_mk_ullong(0xFE00000000)
> +
> +#define GUEST_RAM_BANK_BASES   { GUEST_RAM0_BASE, GUEST_RAM1_BASE }
> +#define GUEST_RAM_BANK_SIZES   { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE }

Why's this needed in the public header?

Jan