other: 0.742
debug: 0.729
semantic: 0.658
performance: 0.607
device: 0.596
graphic: 0.384
vnc: 0.359
network: 0.346
permissions: 0.345
socket: 0.339
KVM: 0.247
PID: 0.228
boot: 0.220
files: 0.188

ARM: HCR.TSW traps are not implemented

On 32-bit and 64-bit ARM platforms, setting HCR.TSW is supposed to "Trap data or unified cache maintenance instructions that operate by Set/Way." Quoting the ARM manual:

If EL1 is using AArch64 state, accesses to DC ISW, DC CSW, DC CISW are trapped to EL2, reported using EC syndrome value 0x18.
If EL1 is using AArch32 state, accesses to DCISW, DCCSW, DCCISW are trapped to EL2, reported using EC syndrome value 0x03.

However, QEMU does not trap those instructions/registers. This was tested on the branch master of the git repo.

Patch posted:
https://<email address hidden>/

Thanks for the quick turn around! I tested both your patches together (it's useful to have both to emulate set/way flushing inside a guest) and I am getting something unexpected. At some point, we are trapping on an access to DACR but ESR_EL2 doesn't seem to make a lot of sense: 0xfe00dc0. I am running a 32-bit Linux inside a VM.

Decoding it: Rt is set to 0xe which is LR_usr. Also, this is a read operation. So, essentially the guest seems to try to set DACR to LR_usr which seems unreasonable.

It could be an issue with the hypervisor on my side (I am running some custom code). But, it's not obvious to me and the code behaves fine on bare-metal. Is there a chance that ESR is not populated correctly?

In any case, I do see traps for set/way instructions so, from that point of view, the patch is good.



Sorry, I meant the operation is a write (TVM is on). The result of the operation is setting DACR to 0 so the guest stops progressing after that.

Anyway, since the issue could also be on my side, I don't want to block you with this. 

I can't think of any reason that DACR would have an incorrect
register value.  It would be treated as any other system register,
and there's only one code path involved.

Makes sense. Debugging is on me then :) Both patches behave as expected, thanks!

Fixed here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=1803d2713b29