Re: [PATCH v3 16/39] xen/riscv: decouple INSN_PSEUDO_VS_* from the hypervisor's XLEN

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.09.2026 18:23, Oleksii Kurochko wrote:
> htinst reports a pseudoinstruction when a guest page fault is taken on an
> implicit memory access done for VS-stage address translation. Four such
> values are defined, differing in the access type (read or write) and in the
> access width: 4 bytes (0x2000/0x2020) or 8 bytes (0x3000/0x3020).
> 
> That width is the width of a VS-stage PTE, i.e. it follows the guest's
> paging mode (4 bytes for Sv32, 8 bytes for Sv39 and wider) and has nothing
> to do with the XLEN Xen itself is built for. Yet only one pair is defined,
> selected by Xen's XLEN and named as if it were the only one, so the 4-byte
> forms, which a guest running with VSXL=32 and Sv32 in vsatp produces, can't
> be named at all on RV64.
> 
> Define all four values unconditionally instead, named after the access width
> they encode rather than after the build's XLEN.
> 
> Dropping the ladder loses no build-time coverage: a build for an XLEN other

Nit: "latter" (no matter that some Americans may pronounce it like "ladder")

> than 32 or 64 already fails on the equivalent ladders in asm/asm.h and
> asm/config.h, so no replacement #error is needed here. Adding one keyed on
> CONFIG_RISCV_* would in any case re-introduce exactly the conflation this
> patch removes.
> 
> This diverges from the imported version of riscv_encoding.h.
> 
> No functional change: the values have no user.
> 
> Signed-off-by: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>