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

Oleksii Kurochko <[email protected]> Tue, 28 Jul 2026 17:47:38 +0200
Newsgroups gmane.comp.emulators.xen.devel
Message-ID <[email protected]>

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

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.

~ Oleksii