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
