summary refs log tree commit diff stats
path: root/results/classifier/deepseek-1/output/hypervisor/1863685
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/deepseek-1/output/hypervisor/1863685')
-rw-r--r--results/classifier/deepseek-1/output/hypervisor/186368536
1 files changed, 0 insertions, 36 deletions
diff --git a/results/classifier/deepseek-1/output/hypervisor/1863685 b/results/classifier/deepseek-1/output/hypervisor/1863685
deleted file mode 100644
index 52a234b86..000000000
--- a/results/classifier/deepseek-1/output/hypervisor/1863685
+++ /dev/null
@@ -1,36 +0,0 @@
-
-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
-