Random corruption on SpacemiT K1 (and K3) with RVV

[Aurelien Jarno]

Hi,

I have finally been able to capture the last few exceptions happening 
for one event where the vectored user copy code is corrupting data. That 
was on the SpacemiT K1.

I added a hook to handle_exception(), activated only when 
__asm_vector_usercopy_sum_enabled is running, and recording CPU state at 
the beginning of the exception, in per-CPU 16-entry tables.
On the OpenSBI side, I also instrumented sbi_trap_handler() to log the 
CAUSE_MISALIGNED_LOAD and CAUSE_LOAD_ACCESS cases. This only fires
during the kernel boot when it tries to measure speed of unaligned 
accesses.

The case I captured was a 4096-byte long copy, from 0x2a883310 
(userland) to 0xffffffd701e54000 (kernel), presumably from a write 
syscall. The copy is considered successful, i.e it exits with a0=0. That 
said after the copy, the source and the destination start to differ 
after the first 16 bytes, at address 0xffffffd701e54010.

The copy started on CPU 5 and ended on CPU 5, and there was only a 
single exception between the start and the end, so it wasn't 
rescheduled.

The exception happened with epc=0xffffffff80e09204, which corresponds to 
the location of the "vle8.v v0,(a1)" instruction. I recorded:
- cause=0xd
- badaddr=0x2a883410
- a0=0xffffffd701e54100
- a1=0x2a883410
- a2=0xf00
- vl=0x100
- vstart=0x0
- vtype=0xc3

As you can see, the exception happened during the second iteration of 
the loop. It is not clear to me why the first iteration didn't trigger a 
page fault, as both 0x2a883310 and 0x2a883410 are on the same 4k page. I 
have also logged the content of v0 at the time of the exception, and I 
can clearly see that only the first 16 bytes (out of 32 bytes) got 
loaded during the previous iteration. Its content matches the error 
reported by GNU as on the userland side.

Then the remaining of the loop continued without exception to copy 4096 
bytes in total.

At this stage, I do not have any other explanation than a CPU bug. That 
said, I have noticed that the problem started when userland started to 
use the vector extension, and with the above, I do not have any 
explanation for the link between the two. I'll try to capture another
corruption event (it takes ages) to see if it can help refine the 
explanation.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien at aurel32.net                     http://aurel32.net