RISC-V: sc.w writes failure to rd instead of raising access fault
<!--This is the upstream QEMU issue tracker.
If you are able to, it will greatly facilitate bug triage if you attempt
to reproduce the problem with the latest qemu.git master built from
source. See https://www.qemu.org/download/#source for instructions on
how to do this.
QEMU generally supports the last two releases advertised on
https://www.qemu.org/. Problems with distro-packaged versions of QEMU
older than this should be reported to the distribution instead.
See https://www.qemu.org/contribute/report-a-bug/ for additional
guidance.
If this is a security issue, please consult
https://www.qemu.org/contribute/security-process/-->
## Host environment
- Operating system:
AlmaLinux 9.7
- Architecture:
x86_64
- QEMU flavor:
qemu-system-riscv64
- QEMU version:
QEMU emulator version 10.2.0 (v10.2.0)
- QEMU command line:
1. `qemu-system-riscv64 -S -M virt -nographic -bios none -kernel ExceptionsZalrsc-00.elf -gdb tcp::1234`
## Emulated/Virtualized environment
- Operating system:
bare-metal test
- OS/kernel version:
N/A
- Architecture:
riscv64
## Description of problem
I am writing a test to exercise the sc.w access fault exception for the Zalrsc extension. I do not yet have a standalone QEMU trace log, but I reproduced this under GDB with a minimal test case. In GDB, `lr.w` to the faulting address traps as expected, while `sc.w` to the same address does not trap and instead writes `1` to `rd`.
In the attached code, the sc.w instruction happens when pc is at:
```null
8000041c
```
## Steps to reproduce
1. Start QEMU and wait for GDB to attach:
`qemu-system-riscv64 -S -M virt -nographic -bios none -kernel ExceptionsZalrsc-00.elf -gdb tcp::1234`
2. In another terminal, attach GDB:
`riscv64-unknown-elf-gdb -ex "target remote :1234" -iex "file ExceptionsZalrsc-00.elf"`
3. In GDB, display the current instruction and continue to the `lr.w` access-fault test:
`display /i $pc`
`b ExceptionsZalrsc_cg_cp_store_access_fault_lr_w_store_fault`
`c`
4. Single-step the `lr.w` and observe that execution transfers to the trap handler:
`stepi`
5. Continue to the `sc.w` access-fault test:
`b ExceptionsZalrsc_cg_cp_store_access_fault_sc_w_fault`
`c`
6. Check the destination register before and after stepping the `sc.w`
(In this case, x26 is the rd register of the sc.w instruction):
`p/x $x26`\
`stepi`\
`p/x $x26`
Expected behavior:
* `sc.w` should raise a store/AMO access fault exception rather than returning 1 in rd.
Observed result:
* `lr.w` traps as expected.
* `sc.w` does not trap.
* after stepping `sc.w`, `x26` is modified to `1`
## Additional information
This issue might be related to the following QEMU issue involving LR/SC handling:
https://gitlab.com/qemu-project/qemu/-/issues/3136
Both issues involve incorrect behavior of LR/SC instructions, although the symptoms appear different. My issue concerns exception handling for `sc.w` on a faulting address, while #3136 discusses reservation handling. Hope this is helpful!
<!--The line below ensures that proper tags are added to the issue.
Please do not remove it.-->
issue