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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 6/15/26 5:36 PM, Jan Beulich wrote:
> On 08.05.2026 16:43, 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 currently perform no
> > additional work but allow the generic dom0less code to build and run
> > on RISC-V.
> >
> > Introduce max_init_domid as a runtime variable rather than a constant
> > so that it can be updated during dom0less domain creation.
> >
> > 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 in the public
> > RISC-V interface.
> >
> > As HAS_DOM0LESS is selected for RISC-V now it could be a compilation
> > issue if CONFIG_STATIC_MEMORY=y as guest_physmap_add_pages() isn't
> > yet provided.
> >
> > Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
> > ---
> > Changes in v2:
> >   - Move declaration of p2m_set_allocation() to p2m-common.h.
> >   - Add __initdata for max_init_domid and drop initalizer for it.
> >   - Add CONFIG_STATIC_MEMORY=n to CI's randconfig to avoid
> >     compilation error because of guest_physmap_add_pages()
> >     isn't provided.
> Yet another trap for people to fall into, and yet another item to clean
> up before the port is really ready to use. Imo there want to be
> HAS_STATIC_MEMORY, which RISC-V simply wouldn't select (for the time
> being).
Sounds good to me. I will do the following then in the separate patch:
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig

index 683ab7d25a1e..d748404e82da 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -22,6 +22,7 @@ config ARM
        select HAS_GRANT_CACHE_FLUSH if GRANT_TABLE
        select HAS_SHARED_INFO
        select HAS_STACK_PROTECTOR
+       select HAS_STATIC_MEMORY
        select HAS_UBSAN

 config ARCH_DEFCONFIG
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 8b48d84c79e8..6e24f7f4e43b 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -161,6 +161,9 @@ config HAS_SCHED_GRANULARITY
 config HAS_SHARED_INFO
        bool

+config HAS_STATIC_MEMORY
+       bool
+
 config HAS_SOFT_RESET
        bool

@@ -196,7 +199,7 @@ config NUMA

 config STATIC_MEMORY
        bool "Static Allocation Support (UNSUPPORTED)" if UNSUPPORTED
-       depends on DOM0LESS_BOOT && HAS_DEVICE_TREE_DISCOVERY
+       depends on HAS_STATIC_MEMORY && DOM0LESS_BOOT && 
HAS_DEVICE_TREE_DISCOVERY
        help
          Static Allocation refers to system or sub-system(domains) for
          which memory areas are pre-defined by configuration using 
physical
> > --- a/xen/arch/riscv/dom0less-build.c
> > +++ b/xen/arch/riscv/dom0less-build.c
> > @@ -102,3 +102,9 @@ int __init arch_parse_dom0less_node(struct dt_device_node 
> > *node,
> >   
> >       return 0;
> >   }
> > +
> > +int __init arch_handle_passthrough_prop(struct kernel_info *kinfo,
> > +                                        struct dt_device_node *node)
> > +{
> > +    return 0;
> > +}
> No FIXME comment or anything alike? That is, nothing is going to be needed
> here even once pass-through is supported?
At the moment (even in downstream), RISC-V has nothing to do. I can just 
add the comment above return:
 /* Nothing specific to do for now */

> > --- a/xen/arch/riscv/domain-build.c
> > +++ b/xen/arch/riscv/domain-build.c
> > @@ -158,9 +158,22 @@ int __init make_cpus_node(const struct domain *d, struct 
> > kernel_info *kinfo)
> >       return fdt_end_node(fdt);
> >   }
> >   
> > +int __init construct_hwdom(struct kernel_info *kinfo,
> > +                           const struct dt_device_node *node)
> > +{
> > +    return -EOPNOTSUPP;
> > +}
> > +
> >   int __init make_timer_node(const struct kernel_info *kinfo)
> >   {
> >       /* There is no need for timer node for RISC-V. */
> >   
> >       return 0;
> >   }
> > +
> > +int __init make_hypervisor_node(struct domain *d,
> > +                                const struct kernel_info *kinfo,
> > +                                int addrcells, int sizecells)
> The last two parameters being of plain int type is, I suppose, dictated
> by DT code?
Yes, it is dictated by DT code.

> > --- a/xen/arch/riscv/include/asm/guest-layout.h
> > +++ b/xen/arch/riscv/include/asm/guest-layout.h
> > @@ -24,4 +24,7 @@
> >   #define GUEST_RAM_BANK_BASES   { GUEST_RAM0_BASE, GUEST_RAM1_BASE }
> >   #define GUEST_RAM_BANK_SIZES   { GUEST_RAM0_SIZE, GUEST_RAM1_SIZE }
> >   
> > +#define GUEST_MAGIC_BASE  xen_mk_ullong(0x39000000)
> > +#define GUEST_MAGIC_SIZE  xen_mk_ullong(0x01000000)
> Why xen_mk_ullong()? That's needed in the public headers only, iirc.
I didn't know that it is only for public headers.

I can change that to _ULL.

> Also these are again two seemingly arbitrary numbers.
It is pretty arbitrary, I just took what isn't used by QEMU machine for 
its address space. I double checked and it should be changed to 
something else as it falls into PCIE_ECAM range:
    [VIRT_PCIE_ECAM] =    { 0x30000000,    0x10000000 },
    [VIRT_PCIE_MMIO] =    { 0x40000000,    0x40000000 },
    [VIRT_DRAM] =         { 0x80000000,           0x0 },

I will use 0x79000000 instead.

I will update the commit message that it GUEST_MAGIC_BASE and 
GUEST_MAGIC_SIZE are chosen arbitary and not to overlap with address 
space provided by QEMU for RISC-V machine.
Thanks.

~ Oleksii