1 files changed, 48 insertions, 0 deletions
diff --git a/results/classifier/105/instruction/1863685 b/results/classifier/105/instruction/1863685
new file mode 100644
index 000000000..ae214b91a
--- /dev/null
+++ b/results/classifier/105/instruction/1863685
@@ -0,0 +1,48 @@
+instruction: 0.867
+other: 0.742
+semantic: 0.658
+mistranslation: 0.656
+device: 0.596
+graphic: 0.384
+vnc: 0.359
+network: 0.346
+socket: 0.339
+assembly: 0.324
+KVM: 0.247
+boot: 0.220
+
+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
+