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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 9/2/26 4:58 PM, Jan Beulich wrote:
> 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>
Thanks.

> 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.)
Good point. I will use token concatenation.

Regarding parameter name I have several options in mind: guests or 
guest_xlens.
I prefer 'guests' at the moment but I am open to adjust to better naming 
before sending v9.
~ Oleksii