blob: 1d721abd39744bda751c57ac665f9180370c5403 (
plain) (
blame)
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
|
KVM: 0.962
mistranslation: 0.953
graphic: 0.944
virtual: 0.917
debug: 0.908
kernel: 0.841
VMM: 0.739
device: 0.737
performance: 0.732
ppc: 0.657
TCG: 0.640
x86: 0.636
vnc: 0.631
register: 0.628
risc-v: 0.623
architecture: 0.613
hypervisor: 0.611
PID: 0.515
user-level: 0.503
semantic: 0.495
network: 0.489
socket: 0.483
files: 0.456
permissions: 0.438
peripherals: 0.403
i386: 0.390
arm: 0.384
boot: 0.329
assembly: 0.250
softmmu 'at' not behaving
Description of problem:
This looks like a bug to me, please correct if I'm wrong. The execution context is EL2 here and we run KVM vms on top of the system emulation. Anyway, here we have stopped in the EL2 and want to translate a virtual address '0' with 'at'. While the '0' itself is not mapped, something in the first gigabyte is, and the softmmu refuses to walk to it:
0x0000000100004a3c <at_s12e1r+8>: 80 78 0c d5 at s12e1r, x0
0x0000000100004a40 <at_s12e1r+12>: 01 74 38 d5 mrs x1, par_el1
(gdb) info registers x0 x1
x0 0x0 0
x1 0x809 2057
So that would be translation fault level 0, stage 1 if I'm not mistaken.
(gdb) info all-registers TCR_EL1 VTCR_EL2 TTBR1_EL1
TCR_EL1 0x400035b5503510 18014629184681232
VTCR_EL2 0x623590 6436240
TTBR1_EL1 0x304000041731001 217298683118686209
(gdb) p print_table(0x41731000)
000:0x000000ffff9803 256:0x000000fffff803 507:0x00000041fbc803
508:0x000000ff9ef803
The first gigabyte is populated, yet the 'at' knows nothing about it. Did I miss something? This seems to be working fine on the hardware.
Steps to reproduce:
1. Stop in the EL2 while the linux is running (GDB)
2. Use something along the lines of this function to translate any kernel virtual address: https://github.com/jkrh/kvms/blob/4c26c786be9971613b3b7f56121c1a1aa3b9585a/core/helpers.h#L74
|