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

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 6/24/26 2:40 PM, Jan Beulich wrote:
> On 24.06.2026 12:43, Oleksii Kurochko wrote:
> > On 6/22/26 4:09 PM, Jan Beulich wrote:
> > > On 17.06.2026 13:17, Oleksii Kurochko wrote:
> > > > Introduce generation of the riscv,isa string passed to the guest via the
> > > > Device Tree riscv,isa property.
> > > >
> > > > Introduce the per-domain isa string and guest isa bitmap, populated
> > > > during domain creation by calling init_guest_isa().
> > > >
> > > > Introduce guest_unsupp 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.
> > > I may have asked before - what about Zfinx, Zdinx (and the supposed Zqinx)?
> > > They aren't in riscv_isa_ext[], yes, but perhaps wrongly so? And hence they
> > > may want at least mentioning?
> > They are not supported by Xen so they aren't in riscv_isa_ext so it
> > looks fine for me.
> >
> > They are not in guest_unsupp as they aren't present in riscv_isa_ext and
> > so it won't be propagated to guest anyway because of:
> >     +    bitmap_andnot(d->arch.isa, riscv_isa, guest_unsupp,
> >     +                  RISCV_ISA_EXT_MAX);
> >
> > While it isn't in riscv_isa_ext[] I think it is fine not to add them to
> > guest_unsupp, so I will add to the commit message that:
> > ```
> > - Zfinx, Zdinx and Zqinx are not implemented for guests either; as they
> > are not present in the riscv_isa_ext[] array, they can never be set in
> > riscv_isa and thus are never exposed to a guest, so there is no need to
> > list them explicitly in guest_unsupp.
> > ```
> >
> > I think it is fine for now but probably it will need to be reworked in
> > future.
> Especially as long as F/D/Q aren't supported by Xen, I would consider it
> pretty desirable to allow the (cheaper to implement on the Xen side) Z*inx.
> Provided of course there's actual hardware offering any of Z*inx in place
> of F/D (not so much Q).
I agree Z*inx would be cheaper for Xen to support, precisely because it 
keeps FP values in the integer registers that Xen already saves and 
restores on context switch, so there's no extra state to manage (unlike 
F/D/Q).
That said, I'd prefer to leave it as future work rather than handle it 
in this series:
Z*inx aren't in riscv_isa_ext[], so they can never be set in riscv_isa 
and are never exposed to a guest today. Nothing here blocks adding them 
later; it would be a separate enablement step.
I couldn't find any board (with or without H) advertising Zinx in its DT 
— manufacturers seem to ship F/D instead.
To my knowledge Linux mainline has no Z*inx support, so a Linux guest 
expects F/D anyway. And per the unprivileged spec, software assuming F 
is incompatible with software assuming Zfinx and vice versa, so the two 
can't be transparently substituted.
So for now it doesn't make much sense to enable Z*inx for Xen and/or 
guests, but it's a reasonable future enhancement once hardware and 
guest-OS support materialize.
~ Oleksii