Re: [PATCH v8 04/20] xen/riscv: introduce guest riscv,isa string

[Jan Beulich <jbeulich@xxxxxxxx>]

On 27.08.2026 17:18, Oleksii Kurochko wrote:
> Introduce build_guest_isa_str() to generate the riscv,isa string to be
> passed to the guest via the Device Tree riscv,isa property.
> 
> Introduce the per-domain guest ISA bitmap, populated during domain
> creation by calling init_guest_isa().
> 
> Introduce struct riscv_isa_ext_entry with a new guest_flags field
> to filter out ISA extensions that should not be exposed to guests:
> 
> - f/d/q/v: FPU and vector context save/restore are not yet implemented
>   for guests.
> - Z*inx are not exposed either: they aren't in riscv_isa_ext[], so they
>   can never be set in riscv_isa and thus never reach a guest, and no
>   current hardware/guest-OS advertises or expects them. Supporting them
>   would be cheaper than F/D/Q (FP values stay in integer registers Xen
>   already context-switches), but is left as future work.
> - h: Nested virtualisation is not supported.
> - sstc: Xen owns the supervisor timer; guests must use SBI.
> - svade: Xen manages hardware A/D bit updates in stage-2 page tables.
> - svpbmt: Page-based memory types are not yet wired up in stage-2 code.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>

In principle
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>
Nevertheless I again have something for you to further consider:

> @@ -34,9 +36,64 @@ struct riscv_isa_ext_data {
>      .name = #ext_name,                          \
>  }
>  
> +/*
> + * Which guests an extension may be handed out to, by guest XLEN.
> + *
> + * These flags express Xen's policy, not the ISA's rules: extensions which
> + * are architecturally tied to one XLEN (Zilsd on RV32, say) need no special
> + * treatment here, as they can only ever appear in the "riscv,isa" of a host
> + * of that XLEN, and guest_isa is masked against the host ISA bitmap anyway.
> + * They are only of use for extensions Xen chooses not to expose to guests of
> + * a given width despite the hardware implementing them.
> + */
> +#define RISCV_ISA_EXT_GUEST_NONE 0
> +#define RISCV_ISA_EXT_GUEST_RV32 (1U << 0)
> +#define RISCV_ISA_EXT_GUEST_RV64 (1U << 1)
> +#define RISCV_ISA_EXT_GUEST_ANY  (RISCV_ISA_EXT_GUEST_RV32 | \
> +                                  RISCV_ISA_EXT_GUEST_RV64)
> +
> +/*
> + * Guests are of the same width as Xen itself for the time being; once guest
> + * XLEN can differ from host XLEN (hstatus.VSXL), this becomes a per-domain
> + * property, just as guest_isa below does.
> + */
> +#if defined(CONFIG_RISCV_32)
> +#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV32
> +#elif defined(CONFIG_RISCV_64)
> +#define RISCV_ISA_EXT_GUEST_XLEN RISCV_ISA_EXT_GUEST_RV64
> +#else
> +# error "Unsupported RISC-V bitness"
> +#endif
> +
> +struct riscv_isa_ext_entry {
> +    unsigned int id;
> +    const char *name;
> +    unsigned int guest_flags;
> +};
> +
> +#define RISCV_ISA_EXT_ENTRY(ext_name, guest_flgs)       \
> +{                                                       \
> +    .id          = RISCV_ISA_EXT_ ## ext_name,          \
> +    .name        = #ext_name,                           \
> +    .guest_flags = guest_flgs,                          \

As you're using token concatenation here already anyway, why not

    .guest_flags = RISCV_ISA_EXT_GUEST_ ## guest_flgs,     \

helping the use sites quite a bit? (Whether guest_flgs [then] is
a good parameter name is a separate question.)

Jan