Re: [PATCH v6 06/23] xen/riscv: introduce guest riscv,isa string

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.07.2026 17:47, Oleksii Kurochko wrote:
> 
> 
> On 7/22/26 9:25 AM, Jan Beulich wrote:
>> On 20.07.2026 17:59, 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_supported 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.
> 
>>
>> But see below.
>>
>>> ---
>>> Changes in v6:
>>> - build_guest_isa_str() now takes a `const struct domain *d` instead of a
>>>    raw `const unsigned long *isa_bitmap`, to leave room for using more than
>>>    just the bitmap in the future.
>>> - Compute the guest-visible ISA bitmap once at boot, into a new
>>>    __ro_after_init `guest_isa` bitmap (compute_guest_isa(), called at the
>>>    end of riscv_fill_hwcap()), instead of re-deriving it from
>>>    riscv_isa_ext[] on every domain creation in init_guest_isa(). All guests
>>>    currently get the same extension set, so this avoids repeating
>>>    identical work per domain; will need revisiting if/when per-domain ISA
>>>    policy is introduced.
>>> - struct arch_domain's `isa` field is now `const unsigned long *isa`
>>>    instead of an embedded bitmap; init_guest_isa() just points it at the
>>>    shared `guest_isa` bitmap rather than copying bits into a per-domain
>>>    array.
>>> - Mark riscv_isa_ext[] __initconstrel, since its entries hold name pointers
>>>    and the need for relocations requires that the compiler emit the data to
>>>    a writable section.
>>> - Make build_guest_isa_str() __init as it is called during make_cpus_node()
>>>    which is used only (at least, for now) in build time of domain.
>>
>> This last item is confusing. For one as there's no call site being added here
>> in the first place. 
> 
> Agree, I have to put that actual call happens in the follow up commit.
> 
> And then - why would the string need re-calculating when
>> the bitmap is calculated once at start of day?
> 
> It isn't re-calculated per call site, only once per domain build. But 
> you're right that today that's still redundant work: the bitmap is 
> shared, so every domain gets the same string. I kept the generation in 
> make_cpus_node() because the string is consumed there and thrown away, 
> and because per-domain ISA policy would put us back to building it per 
> domain anyway.

Which would be true for the bitmap as well. Imo both want treating the
same.

Jan