RISC-V: fsgnj.d/fmv.d retire without F/D extension

[carlosqwqqwq]

RISC-V: fsgnj.d/fmv.d retire without F/D extension

Rechecked revision

The report was rechecked against the public Unicorn dev branch at
938efd13aeab73155f31cf707a2094c6ccaa36dd.

Problem

trans_fsgnj_d, which also implements the fmv.d alias, lacks the FPU and D
extension checks used by neighboring D-extension translators. On
UC_CPU_RISCV64_SIFIVE_E51, whose ISA has neither F nor D, the instruction
retires and guest execution continues instead of raising an illegal-instruction
exception.

Public reproducer

The freestanding witness and runner are available at
https://github.com/carlosqwqqwq/unicorn-riscv-repros/tree/main/u020.
After building the public dev checkout, run:

LIBUNICORN_PATH=/path/to/unicorn/build ./u020/run.sh

The E51 run must raise UC_ERR_EXCEPTION. A D-enabled control remains legal.

Expected behavior

fsgnj.d and its fmv.d alias require F/D support. QEMU with D disabled
rejects the instruction, while a D-enabled CPU executes it.

Root cause and proposed fix

Add REQUIRE_FPU; and REQUIRE_EXT(ctx, RVD); at the start of
trans_fsgnj_d, matching the sibling D-extension translators. The focused
regression is included in PR #2393.

[wtdcode]

Hi @carlosqwqqwq

I appreciate your (research?) efforts improving Unicorn but firstly could you re-run your workflow against our master branch? Thanks in advance.

[carlosqwqqwq]

Hi @wtdcode, thanks for the guidance. You were right to ask for a rerun against the current upstream master.

I have now rerun all five reproducer workflows (#2392–#2396) against Unicorn master 7c5db94191defc1e04a4f66f4eb1220903cba837, which is also the current base of all five PRs, in the x86_64 lab.

For each case, I applied the one-file patch with git apply --check, built both the affected and patched libraries from that master source tree, and ran the affected path together with a positive or isolation control:

• U-009 / riscv: gate counter CSRs on mcounteren at every priv version #2392: the invalid U-mode hpmcounter3 access now traps; the legal M-mode access remains functional.
• U-020 / riscv: gate fsgnj.d/fmv.d on FPU and D extension #2393: fsgnj.d traps on E51 without F/D; a D-enabled U54 with FS enabled reaches exit(42) on both versions.
• U-025 / riscv: reject odd instruction addresses at fetch time #2394: the odd-entry path traps before executing the guest instruction; the aligned control remains functional.
• U-030 / riscv: gate D-width atomic translators on the A extension #2395: D-width atomics trap on an explicit no-A model; W-width controls and A-enabled models remain unchanged.
• U-034 / riscv: keep mstatus.MPP=M after mret on harts without U-mode #2396: mret on an explicit no-U model preserves M-mode; U54 behavior remains unchanged.

The rerun did not reveal a new issue or require changing the submitted patch contents. Each PR remains a single targeted QEMU source-file change, and the patch whitespace checks pass.

Could you please let me know if this is the workflow you had in mind, or point me to a specific upstream command or CI job you would prefer us to run?

[wtdcode]

Hi @wtdcode, thanks for the guidance. You were right to ask for a rerun against the current upstream master.

I have now rerun all five reproducer workflows (#2392–#2396) against Unicorn master 7c5db94191defc1e04a4f66f4eb1220903cba837, which is also the current base of all five PRs, in the x86_64 lab.

For each case, I applied the one-file patch with git apply --check, built both the affected and patched libraries from that master source tree, and ran the affected path together with a positive or isolation control:

• U-009 / riscv: gate counter CSRs on mcounteren at every priv version #2392: the invalid U-mode hpmcounter3 access now traps; the legal M-mode access remains functional.
• U-020 / riscv: gate fsgnj.d/fmv.d on FPU and D extension #2393: fsgnj.d traps on E51 without F/D; a D-enabled U54 with FS enabled reaches exit(42) on both versions.
• U-025 / riscv: reject odd instruction addresses at fetch time #2394: the odd-entry path traps before executing the guest instruction; the aligned control remains functional.
• U-030 / riscv: gate D-width atomic translators on the A extension #2395: D-width atomics trap on an explicit no-A model; W-width controls and A-enabled models remain unchanged.
• U-034 / riscv: keep mstatus.MPP=M after mret on harts without U-mode #2396: mret on an explicit no-U model preserves M-mode; U54 behavior remains unchanged.

The rerun did not reveal a new issue or require changing the submitted patch contents. Each PR remains a single targeted QEMU source-file change, and the patch whitespace checks pass.

Could you please let me know if this is the workflow you had in mind, or point me to a specific upstream command or CI job you would prefer us to run?

Oh sorry my bad. I mean dev branch, not master branch.

[carlosqwqqwq]

Hi @wtdcode, thanks for the guidance. You were right to ask for a rerun against the current upstream master.
I have now rerun all five reproducer workflows (#2392–#2396) against Unicorn master 7c5db94191defc1e04a4f66f4eb1220903cba837, which is also the current base of all five PRs, in the x86_64 lab.
For each case, I applied the one-file patch with git apply --check, built both the affected and patched libraries from that master source tree, and ran the affected path together with a positive or isolation control:

• U-009 / riscv: gate counter CSRs on mcounteren at every priv version #2392: the invalid U-mode hpmcounter3 access now traps; the legal M-mode access remains functional.
• U-020 / riscv: gate fsgnj.d/fmv.d on FPU and D extension #2393: fsgnj.d traps on E51 without F/D; a D-enabled U54 with FS enabled reaches exit(42) on both versions.
• U-025 / riscv: reject odd instruction addresses at fetch time #2394: the odd-entry path traps before executing the guest instruction; the aligned control remains functional.
• U-030 / riscv: gate D-width atomic translators on the A extension #2395: D-width atomics trap on an explicit no-A model; W-width controls and A-enabled models remain unchanged.
• U-034 / riscv: keep mstatus.MPP=M after mret on harts without U-mode #2396: mret on an explicit no-U model preserves M-mode; U54 behavior remains unchanged.

The rerun did not reveal a new issue or require changing the submitted patch contents. Each PR remains a single targeted QEMU source-file change, and the patch whitespace checks pass.
Could you please let me know if this is the workflow you had in mind, or point me to a specific upstream command or CI job you would prefer us to run?

Oh sorry my bad. I mean dev branch, not master branch.

OK...

[carlosqwqqwq]

Hi @wtdcode, thanks for clarifying. I have now rerun the complete reproduction set against the upstream dev branch at commit 938efd13aeab73155f31cf707a2094c6ccaa36dd.

The reported defects are reproducible on this development branch, and the corresponding patches are correct and applicable there. Each patch applies cleanly, builds successfully, and changes only the intended QEMU source file. The results are:

• riscv: gate counter CSRs on mcounteren at every priv version #2392: user-mode counter CSR access is rejected when it is not permitted, while the legal machine-mode access remains functional.
• riscv: gate fsgnj.d/fmv.d on FPU and D extension #2393: fsgnj.d/fmv.d is rejected on a processor without F/D, while a D-enabled U54 with floating-point state enabled executes normally.
• riscv: reject odd instruction addresses at fetch time #2394: an odd instruction address is rejected at fetch time, while an aligned entry point remains functional.
• riscv: gate D-width atomic translators on the A extension #2395: D-width atomic instructions trap on a no-A processor; W-width controls and A-enabled processors remain functional.
• riscv: keep mstatus.MPP=M after mret on harts without U-mode #2396: mret preserves M-mode on a processor without U-mode, while U54 behavior remains unchanged.

These results confirm that the findings are not artifacts of the master snapshot and that the patches address the reported defects without changing the legal control paths. No additional patch change was required.

The five PRs still target master; this run was specifically an applicability check against dev. Please let me know if you would like the PRs to be rebased or retargeted to dev.

[wtdcode]

Yes, please retargeted to dev branch.