From d0c85e36e4de67af628d54e9ab577cc3fad7796a Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 3 Jul 2025 07:27:52 +0000 Subject: add deepseek and gemma results --- results/classifier/gemma3:12b/hypervisor/1879587 | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 results/classifier/gemma3:12b/hypervisor/1879587 (limited to 'results/classifier/gemma3:12b/hypervisor/1879587') diff --git a/results/classifier/gemma3:12b/hypervisor/1879587 b/results/classifier/gemma3:12b/hypervisor/1879587 new file mode 100644 index 000000000..05b82f8ad --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1879587 @@ -0,0 +1,21 @@ + +Register number in ESR is incorrect for certain banked registers when switching from AA32 to AA64 + +I am running into a situation where I have: +- A hypervisor running in EL2, AA64 +- A guest running in EL1, AA32 + +We trap certain accesses to special registers such as DACR (via HCR.TVM). One instruction that is trapped is: + +ee03ef10 -> mcr 15, 0, lr, cr3, cr0, {0} + +The guest is running in SVC mode. So, LR should refer to LR_svc there. LR_svc is mapped to X18 in AA64. So, ESR should reflect that. However, the actual ESR value is: 0xfe00dc0 + +If we decode the 'rt': +>>> (0xfe00dc0 >> 5) & 0x1f +14 + +My understanding is that 14 is incorrect in the context of AA64. rt should be set to 18. The current mode being SVC, LR refers to LR_svc not LR_usr. In other words, the mapping between registers in AA64 and AA32 doesn't seem to be accounted for. I've tested this with Qemu 5.0.0 + +Let me know if that makes sense and if you would like more info. I am also happy to test patches. +Thanks for all the great work on Qemu! \ No newline at end of file -- cgit 1.4.1