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 <[email protected]>
In principle Acked-by: Jan Beulich <[email protected]> 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
