RISC-V: sc.w writes failure to rd instead of raising access fault

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:

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:

#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!

Edited by Jinghe Yu