1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
mistranslation: 0.690
architecture: 0.638
arm: 0.502
kernel: 0.418
graphic: 0.395
semantic: 0.304
device: 0.297
performance: 0.292
peripherals: 0.257
user-level: 0.254
network: 0.239
assembly: 0.212
hypervisor: 0.197
x86: 0.191
register: 0.189
socket: 0.185
permissions: 0.180
vnc: 0.175
ppc: 0.175
PID: 0.150
debug: 0.141
files: 0.131
boot: 0.127
KVM: 0.114
VMM: 0.110
risc-v: 0.105
TCG: 0.098
virtual: 0.097
i386: 0.083
ARM: tag bits cleared in FAR_EL1
The ARM Architecture Reference Manual provides the following for FAR_EL1:
"For a Data Abort or Watchpoint exception, if address tagging is enabled for the address accessed by the data access that caused the exception, then this field includes the tag."
However, I have found that the tag bits in FAR_EL1 are always clear, even if the tag bits were set in the original access.
I can reproduce the problem on both 4.1.1 and master (6e8a73e911f066527e775e04b98f31ebd19db600).
As it happens, I posted some cleanups for this last week:
https://<email address hidden>/
Some of them have been queued to Peter's target-arm.next branch,
but that hasn't made it to master yet.
Actually, I take that back: Peter has merged my TBI patch set,
and is included in 6e8a73e911f066.
Do you have a test case?
Ho hum, I must have been asleep last night.
Peter only merged 7 of 9 patches. The final 2 were re-posted:
https://<email address hidden>/
which includes the critical change that affects FAR_ELx.
With those two patches applied I can no longer reproduce the problem, thanks!
For posterity, this is how I've been reproducing the problem:
1. Build a Linux kernel with this patch applied: https://patchwork.kernel.org/patch/11435077/
2. Run this program under the kernel:
#include <stdint.h>
#include <stdio.h>
#include <signal.h>
void handler(int signo, siginfo_t *siginfo, void *context) {
uint32_t *begin = (uint32_t *)context;
uint32_t *end = ((uint32_t *)context) + (sizeof(ucontext_t)/4);
for (uint32_t *i = begin; i != end; ++i) {
printf("%08p %08x\n", i, *i);
}
_exit(0);
}
int main() {
struct sigaction sa;
sa.sa_sigaction = handler;
sa.sa_flags = SA_SIGINFO;
sigaction(SIGSEGV, &sa, 0);
return *(int *)((1ULL << 56) + 0x123456);
}
I would expect this program's output to include something like the following:
0xffffd5869bd0 46415201
0xffffd5869bd4 00000010
0xffffd5869bd8 00123456
0xffffd5869bdc 01000000
But the output that I was seeing with the bad qemu looked like this:
0xffffd5869bd0 46415201
0xffffd5869bd4 00000010
0xffffd5869bd8 00123456
0xffffd5869bdc 00000000
Fix now in master.
Fixed here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=38d931687fa1
|