Re: [PATCH v4 25/25] xen/riscv: add initial dom0less infrastructure support

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 6/30/26 9:28 AM, Jan Beulich wrote:
> On 26.06.2026 17:46, Oleksii Kurochko wrote:
> > Enable dom0less support for RISC-V by selecting HAS_DOM0LESS and
> > providing the minimal architecture hooks required by the common
> > dom0less infrastructure.
> >
> > Add stub implementations for architecture-specific helpers used when
> > building domains from the device tree. These allow the generic
> > dom0less code to build and let a basic DomU be constructed on RISC-V.
> > construct_hwdom() and make_hypervisor_node() are still stubs returning
> > an error: Dom0/hwdom construction isn't supported yet, and the
> > hypervisor node generation (needed by domains with
> > DOM0LESS_ENHANCED_NO_XS set) is not implemented. Both are marked with
> > a TODO and are not reached by the currently supported configurations.
> >
> > Provide missing helpers and definitions required by the domain
> > construction code, including domain bitness helpers and the
> > p2m_set_allocation() prototype.
> >
> > Additionally define the guest magic memory region (GUEST_MAGIC_BASE /
> > GUEST_MAGIC_SIZE) in asm/guest-layout.h. The base is arbitrary; the
> > only constraint is that the region must not overlap guest RAM or the
> > emulated device regions. It is placed in the unused gap below
> > GUEST_RAM0_BASE (0x80000000); the constraints are documented next to
> > the #define-s.
> >
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
> Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
Thanks.

> Nevertheless, ...
>
> > --- a/xen/arch/riscv/include/asm/guest-layout.h
> > +++ b/xen/arch/riscv/include/asm/guest-layout.h
> > @@ -32,4 +32,16 @@
> >   #define GUEST_RAM_BANK_BASES   { GUEST_RAM0_BASE, GUEST_RAM1_BASE }
> >   #define GUEST_RAM_BANK_SIZES   { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE }
> >   
> > +/*
> > + * The guest magic region holds Xen-reserved pages mapped into the guest's
> > + * physical address space (shared info, grant table, etc.). The only real
> > + * constraint is that the GUEST_MAGIC_SIZE-byte region must not overlap
> > + * guest RAM (the GUEST_RAMx banks) or the emulated device regions defined
> > + * above; the exact base is otherwise arbitrary. Here it is placed in the
> > + * unused gap below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM
> > + * bank would work equally well.
> > + */
> > +#define GUEST_MAGIC_BASE  _UL(0x79000000)
> > +#define GUEST_MAGIC_SIZE  _UL(0x01000000)
> ... while 16Mb may seem a lot, it feels pretty little for 64-bit guests.
> Even in just Sv39 mode they have ample VA space to map a bigger region.
> (As iirc indicated before, a static upper bound looks questionable to me
> anyway.)
I think the comment should be updated as for grants will be separate region.

For all others, it looks like 16MB is more then enough. For example, Arm 
has only 4 used pages (CONSOLE=0, XENSTORE=1, MEMACCESS=2, VUART=3).
So will you be okay with reworking of the comment to:
/*
 * The guest magic region holds the Xen-reserved pages mapped into the
 * guest's physical address space. The only real constraint on
 * GUEST_MAGIC_BASE/SIZE is that the region must not overlap guest RAM
 * (the GUEST_RAMx banks) or the emulated device regions defined above;
 * the exact base is otherwise arbitrary. Here it is placed in the 
unused gap
 * below GUEST_RAM0_BASE (0x80000000), but a hole after a RAM bank 
would work
 * equally well.
 */

And add to the commit message that:
```
A separate region for grant tables will be introduced at the same time 
as the introduction of the grant table for RISC-V.
```

~ Oleksii