riscv / riscv-test-env Goto Github PK

I am not sure whether this issue is related to QEMU for RISC-V or the test infrastructure.

When I am trying to run a test (e.g. one from riscv-tests/isa or one generated by riscv-torture) in QEMU for RISC-V, I get the following error:

    HTIF tohost must be 8 bytes

When I comment out the following lines of code in the riscv_test.h file and recompile the test, the problem disappears:

    .pushsection .tohost,"aw",@progbits;                            \
    .align 6; .global tohost; tohost: .dword 0;                     \
    .align 6; .global fromhost; fromhost: .dword 0;                 \
    .popsection;`

This repository needs a a README file describing what this repo is about, and how it works, etc. I was redirected here by a mailing list conversation, but I can't ascertain what this code repository holds.

@aswaterman
I don't think that the RISC-V spec mandates that hardware-page table walks should be cached. Am I right? If so, then any updates to the page-table in the vm.c should be followed by a fence to make sure that the subsequent page-walks see the updated entries in the page-table.

While I don't completely understand the working of the vm.c. But doing the following changes got the required result. I am sure there is a better solution to this than what is below.

Change-1:

sret in the following should be preceded by a fence

Change-2
sfence in the following should be followed by a fence

I have RAM with random values. When I run the * -v- * tests, they fall. The selected assert does not pass. cause of the trap is CAUSE_FETCH_PAGE_FAULT instead of CAUSE_STORE_PAGE_FAULT. I fall into the branch with assert because user_l3pt [addr / PGSIZE] contains bit A. However, it does not contain bit V. If I reset all memory intended for PAGE TABLE, the test passes.

Why does RVTEST_FAIL macro have a sll followed by a or to TESTNUM?

#define RVTEST_FAIL \ fence; \ 1: beqz TESTNUM, 1b; \ sll TESTNUM, TESTNUM, 1; \ or TESTNUM, TESTNUM, 1;

Eg. TESTNUM of 2 gets converted to 5.
Also fesvr returns (tohost = 2) when we run this in Spike.

This will fail on -march=rv64iv because csrwi fcsr, 0 is an illegal instruction due to absence of misa.F.
If I understand correctly, riscv-v-spec does not assume the presence of floating point, i.e. misa.V does not imply misa.F.
I suggest rename this macro to RVTEST_FP_VECTOR_ENABLE and use it in RVTEST_RV[xlen]UFV, and create macros for vector without FP.

Of medeleg, the architecture says "An implementation can choose to subset the delegatable traps, with the supported delegatable bits found by writing one to every bit location, then reading back the value in medeleg or mideleg to see which bit positions hold a one." Presumably, an implementation can hard-wire medeleg to 0.

The spec also says "For exceptions that cannot occur in less privileged modes, the corresponding medeleg bits should be hardwired to zero." That means that in implementations that have misa.C hard-wired to 1, medeleg[0] is not only allowed to be hard-wired to 0 (as all bits are) but it is encouraged to be hard-wired to 0.

In riscv_test.h:

        li t0, (1 << CAUSE_LOAD_PAGE_FAULT) |                           \
               (1 << CAUSE_STORE_PAGE_FAULT) |                          \
               (1 << CAUSE_FETCH_PAGE_FAULT) |                          \
               (1 << CAUSE_MISALIGNED_FETCH) |                          \
               (1 << CAUSE_USER_ECALL) |                                \
               (1 << CAUSE_BREAKPOINT);                                 \
        csrw medeleg, t0;                                               \
        csrr t1, medeleg;                                               \
        bne t0, t1, other_exception;                                    \

This means that (if it's not an M-mode-only implementation) those 6 traps must be delegatable to S mode or else it goes to other_exception ("some unhandlable exception occurred"). This reset code should make no assumptions about the delegatability of traps in medeleg, especially misaligned fetches.

This reset code assumption will cause the riscv-tests csr.S test to fail if, for example, misaligned fetches are not delegatable due to misa.C=1 (although presence or absence of C support is not otherwise necessary to run that test).

I am studying riscv-test and I found that CHECK_XLEN in env/p/riscv_test.h is weird.

#if __riscv_xlen == 64
# define CHECK_XLEN li a0, 1; slli a0, a0, 31; bgez a0, 1f; RVTEST_PASS; 1:
#else
# define CHECK_XLEN li a0, 1; slli a0, a0, 31; bltz a0, 1f; RVTEST_PASS; 1:
#endif

I am testing it on spike-riscv64. When I use
# define CHECK_XLEN li a0, 1; slli a0, a0, 31; bltz a0, 1f; RVTEST_PASS; 1: (this is for riscv32)
to test, it still pass. but I thought it should fail.

I am doing some fix, I think this will make the code better

diff --git a/p/riscv_test.h b/p/riscv_test.h
index a08f49e..ed8d221 100644
--- a/p/riscv_test.h
+++ b/p/riscv_test.h
@@ -58,9 +58,9 @@
   .endm
 
 #if __riscv_xlen == 64
-# define CHECK_XLEN li a0, 1; slli a0, a0, 31; bgez a0, 1f; RVTEST_PASS; 1:
+# define CHECK_XLEN li a0, 1; slli a0, a0, 31; bgez a0, 2f; li TESTNUM, 1; RVTEST_FAIL; 2:
 #else
-# define CHECK_XLEN li a0, 1; slli a0, a0, 31; bltz a0, 1f; RVTEST_PASS; 1:
+# define CHECK_XLEN li a0, 1; slli a0, a0, 31; bltz a0, 2f; li TESTNUM, 1; RVTEST_FAIL; 2:
 #endif
 
 #define INIT_XREG

The RVTEST_CODE_BEGIN macro, defined in riscv_test.h uses macro the CHECK_XLEN macro. This macro is defined as:

#if __riscv_xlen == 64
# define CHECK_XLEN li a0, 1; slli a0, a0, 31; bgez a0, 1f; RVTEST_PASS; 1:
#else
# define CHECK_XLEN li a0, 1; slli a0, a0, 31; bltz a0, 1f; RVTEST_PASS; 1:
#endif

I believe this is checking that if 1 is shifted 31 bits then this will be a negative for 32 bit and not negative for 64 bit lengths, and will branch if correct. If this is not correct then RVTEST_PASS is executed. I would expect this to be RVTEST_FAIL. A bug in an implementation meant that the code did not branch but then set the test 'passed' criteria and did the ecall. This gave a false positive. and was picked up because a smaller number of instructions were retired than expected.