On 03.09.2026 09:27, Oleksii Kurochko wrote:
> On 9/2/26 4:58 PM, Jan Beulich wrote:
>> On 27.08.2026 17:18, Oleksii Kurochko wrote:
>>> @@ -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.
I'd suggest singular ("guest"), but I don't mind the plural form.
Jan
