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
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
permissions: 0.987
debug: 0.985
peripherals: 0.981
assembly: 0.978
architecture: 0.977
semantic: 0.975
hypervisor: 0.974
device: 0.973
virtual: 0.972
arm: 0.971
user-level: 0.970
VMM: 0.969
register: 0.968
TCG: 0.966
PID: 0.965
performance: 0.964
kernel: 0.963
socket: 0.963
boot: 0.956
vnc: 0.954
KVM: 0.952
risc-v: 0.949
files: 0.932
mistranslation: 0.925
ppc: 0.904
network: 0.889
graphic: 0.877
x86: 0.770
i386: 0.689
SIE-200 (TrustZone) MPC: BLK_MAX returns an incorrect value
Version:
$ qemu-system-arm --version
QEMU emulator version 3.0.92 (v3.1.0-rc2-31-gd522fba244)
Arm SIE-200 Technical Reference Manual describes that BLK_MAX indicates the maximum value of "block based index register" (BLK_IDX). For example, the value 1 would indicate that BLK_IDX can be 0 or 1. According to my experiments, the AN505 FPGA image apparently follows this behavior.
In the current implementation of QEMU, it appears to indicate the number of possible values for BLK_IDX, i.e., one plus the value it's supposed to return.
As per https://www.qemu.org/contribute/report-a-bug/ could you please provide:
- the command line you are using
- details about the guest you are running (or test case)
Command line:
$ qemu-system-arm -kernel Image.elf -machine mps2-an505 -nographic -d guest_errors -s -semihosting
The guest I'm running is an unreleased program for a research purpose. I'm not aware of any publicly-known application or operating system that make use of the hardware register concerned by this issue.
The attached program is an artificial example that reproduces the issue. The program writes a random value to every LUT block within [0, BLK_MAX]. After that, it examines the content of every LUT block to see if it has the intended value or not.
With the AN505 FPGA image, you get the following output (via UART1, 115200 baud):
==== The test program has started ====
LUT[0x00000000] = 07345a3f
LUT[0x00000001] = 020c7cc6
==== The test program has completed ====
With QEMU, you get the following output because the LUT index 0x00000040 doesn't actually exist and is wrapped around to the first block:
$ make qemu
qemu-system-arm -kernel Image.elf -machine mps2-an505 -nographic -d guest_errors -s -semihosting
==== The test program has started ====
LUT[0x00000000] = 07345a3f
LUT[0x00000001] = 020c7cc6
...
LUT[0x0000003f] = ce3b657b
LUT[0x00000040] = f01ed211
[ERROR] Verify failed at 0x00000000 - expected 0x07345a3f, got 0xf01ed211.
==== The test program has completed ====
Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch:
http://patchwork.ozlabs.org/patch/1013034/
Peter Maydell <email address hidden> writes:
> Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch:
> http://patchwork.ozlabs.org/patch/1013034/
I know you had a bunch of M-profile test cases. Once we get tcg system
tests enabled would it be worth porting some of those into the QEMU src
tree?
There is already one other ARM system test pending for the microbit
tests.
>
>
> ** Changed in: qemu
> Status: New => In Progress
--
Alex Bennée
On Fri, 14 Dec 2018 at 13:56, Alex Bennée <email address hidden> wrote:
>
>
> Peter Maydell <email address hidden> writes:
>
> > Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch:
> > http://patchwork.ozlabs.org/patch/1013034/
>
> I know you had a bunch of M-profile test cases. Once we get tcg system
> tests enabled would it be worth porting some of those into the QEMU src
> tree?
I don't have anything suitable -- unless we have
support for "system test of this guest kernel", in which case
we could add the arm trusted firmware boot/selftests.
thanks
-- PMM
Peter Maydell <email address hidden> writes:
> On Fri, 14 Dec 2018 at 13:56, Alex Bennée <email address hidden> wrote:
>>
>>
>> Peter Maydell <email address hidden> writes:
>>
>> > Thanks for the bug report and the test program. The fix seems straightforward -- just adjust what we return for the register value. I've sent a patch:
>> > http://patchwork.ozlabs.org/patch/1013034/
>>
>> I know you had a bunch of M-profile test cases. Once we get tcg system
>> tests enabled would it be worth porting some of those into the QEMU src
>> tree?
>
> I don't have anything suitable -- unless we have
> support for "system test of this guest kernel", in which case
> we could add the arm trusted firmware boot/selftests.
That's the next step, enabling the building of a known good test case
from an external tree and depositing the images in the right place so we
can use them as tests.
Things like LTP, kvm-unit-tests and various kernels.
>
> thanks
> -- PMM
--
Alex Bennée
This is now fixed in git master, in commit 619d54a8d854e797bf562, and will be in the upcoming 4.0 release.
|