Re: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL

[Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>]

On 8/31/26 2:48 PM, Baptiste Le Duc wrote:
> > hstatus.VSXL is WARL, so its reset value is implementation-defined. Xen
> > supports 64-bit guests only, so program it explicitly instead of relying
> > on whatever the hardware happens to leave there.
> >
> > This matters beyond the guest's own view of itself: decoding a trapped
> > instruction depends on the effective XLEN of the guest, as the encodings
> > which exist for XLEN=64 only must not be recognized for a 32-bit one.
> It's not clear which instruction "decoding a trapped instruction" refers
> to without more context. I assume you mean decode_ldst_insn() in
> emulate.c, but the patch introducing that function comes later in the
> series, so this isn't obvious on a first read.
>
> Please reorder the series so this patch follows the one introducing
> decode_ldst_insn(), or reference it explicitly in the commit message
> (e.g. "load/store trap emulation, introduced later in this series in
> emulate.c, needs...").
I think I can just drop this paragraph from commit message. Even without 
it considering that we are supporting only rv64 guest we should set 
hstatus.VSXL correspondingly and not rely on what hardware will put there.
~ Oleksii