On Wed, Oct 15, 2025 at 04:32:05PM -0500, Andy Chiu wrote:
On Wed, Oct 15, 2025 at 3:18 PM Andy Chiu andybnac@gmail.com wrote:
On Tue, Oct 7, 2025 at 6:58 AM Sergey Matyukevich geomatsi@gmail.com wrote:
When ptrace updates vector CSR registers for a traced process, the changes may not be immediately visible to the next ptrace operations due to vector context switch optimizations.
The function 'riscv_v_vstate_save' saves context only if mstatus.VS is 'dirty'. However mstatus.VS of the traced process context may remain 'clean' between two breakpoints, if no vector instructions were executed between those two breakpoints. In this case the vector context will not be saved at the second breakpoint. As a result, the second ptrace may read stale vector CSR values.
IIUC, the second ptrace should not get the stale vector CSR values. The second riscv_vr_get() should be reading from the context memory (vstate), which is updated from the last riscv_vr_set(). The user's vstate should remain the same since last riscv_vr_set(). Could you explain more on how this bug is observed and why only CSRs are affected but not v-regs as well?
From looking into your test, I can see that you were trying to set an invalid configuration to Vetor CSRs and expect vill to be reflected upon next read. Yes, this is not happening on the current implementation as it was not expecting invalid input from the user, which should be taken into consideration. Thanks for spotting the case!
According to the spec, "The use of vtype encodings with LMUL < SEWMIN/ELEN is reserved, implementations can set vill if they do not support these configurations." This mean the implementation may actually support this configuration. If that is the case, I think we should not allow this to be configured through the vector ptrace interface, which is designed to support 1.0 (and 0.7) specs. That means, we should not allow this problematic configuration to pass through riscv_vr_set(), reach user space, then the forced save.
I would opt for validating all CSR configurations in the first place. Could you also help enforce checks on other reserved bits as well?
Just to clarify, the suggestion is to drop the TIF_RISCV_V_FORCE_SAVE entirely and use only careful validation of input parameter in riscv_vr_set, rather than using both checks. Is that correct?
If that is correct, then I assume we can rely on the simple rule ELEN == XLEN to validate vsew/vlmul supported combinations. Additionally, reserved vsew values (see 3.4.1 in spec) should also be rejected.
Thanks, Sergey