1 files changed, 50 insertions, 0 deletions
diff --git a/results/classifier/108/other/1863685 b/results/classifier/108/other/1863685
new file mode 100644
index 00000000..2c8808f0
--- /dev/null
+++ b/results/classifier/108/other/1863685
@@ -0,0 +1,50 @@
+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
+