I am porting an hypervisor on the Jetson TX2 board and one of my test is checking for a proper implementation for Xen XSA-201 where an hardware virtualized guest could crash the system if it generated an Serror on the system.
The solution for this (which is working perfectly on Jetson TX1 board) is to have a data synchronization barrier (DSB) followed by an instruction synchronization barrier to force asynchronous aborts to occur at this exact point.
To test this, i have a guest doing a write at 0xf0 0000 0000 and going to sleep. The asynchronous abort should fire in EL2 when switching to an other guest. This is exactly what is happening on the Jetson TX1.
On the Jetson TX2 i have 2 effects:
- When i have several cores activated (all other cores then first A57 are in idle in a wfi on my test), the Serror is happening on one of the sleeping cores from time to time
- When i don’t activate the other cores or when the exception is firing on the core 0, it does not occur in EL2 mode after the ISB but sometimes later.
With only the core 0, i have the Serror firing correctly if i “manually” flush the pipeline like this:
mov x15, #0x10000
1:
nop
dsb sy
isb
sub x15, x15, #1
cbnz x15, 1b
Is it possible that the ISB instruction is not properly flushing the instruction pipeline on the TX2 ?
Does anyone else had some weird Serror on different cores then the one actually doing an invalid access ?
Is this a known issue ?
Thanks in advance