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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
|
mistranslation: 0.930
other: 0.927
semantic: 0.926
socket: 0.902
device: 0.884
assembly: 0.883
instruction: 0.868
graphic: 0.868
vnc: 0.864
network: 0.839
KVM: 0.799
boot: 0.766
MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction
I occasionally see that the TLBP instruction fails to find the corresponding TLB entry in the TLB Modified exception handler. This behavior is unexpected, because the invocation of the TLB Modified exception suggests there indeed is such an entry in the TLB and only requires its dirty bit to be set.
The operating system which can trigger and is susceptible to this behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta. The QEMU version on which this is reproducible is QEMU 1.4.0 and also some others.
When I looked into the QEMU sources, I noticed the following discrepancy, which could potentially explain the behavior:
65 /* MIPS32/MIPS64 R4000-style MMU emulation */
66 int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int *prot,
67 target_ulong address, int rw, int access_type)
68 {
<snip>
72 for (i = 0; i < env->tlb->tlb_in_use; i++) {
1865 void r4k_helper_tlbp(CPUMIPSState *env)
1866 {
<snip>
1875 for (i = 0; i < env->tlb->nb_tlb; i++) {
From the above it appears as if the the code which searches the TLB for a matching entry searched also the QEMU-specific "shadow" TLB entries, which is, however, not in line with how the TLBP instruction searches the TLB. So if a matching entry is found on index >= tlb_in_use, the HelenOS exception handler using TLBP to locate the entry would hit an assertion on seeing the Index register bit P set.
I also suspect there is a similar issue with the TLB Invalid exception, but thanks to the specifics of the MIPS 4Kc CPU, HelenOS is not susceptible in this case.
Linux under QEMU does not hit this issue because it turns out that its "TLB modified" handler does not check the P bit of the Index register after the TLBP instruction.
hello,
in the past year gsoc qemu proposed projects there where on eproject that i
liked, which were: qemu IA64 emulation :
http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation
this year i have not seen this project to be proposed, so i would like to
know if the qemu will be selected i would like to know if i will be able to
begin to make this project.
i am also a very novice in the asm programming (so very noobish in the
field, so u will have to answer a lot of noobish questions :) ), so would u
accept such a student to make this project?
i thank you in advance for the answer
best regards
On 04/04/2013 07:34 PM, Gigi D'Agostino wrote:
> in the past year gsoc qemu proposed projects there where on eproject that i
> liked, which were: qemu IA64 emulation :
> http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation
>
> this year i have not seen this project to be proposed, so i would like to
> know if the qemu will be selected i would like to know if i will be able to
> begin to make this project.
> i am also a very novice in the asm programming (so very noobish in the
> field, so u will have to answer a lot of noobish questions :) ), so would u
> accept such a student to make this project?
I can't speak for QEMU as I am from the HelenOS mentoring organization,
but according to how GSoC works, a student is free to suggest any
project. The organizations will then pick the best student applications
for things they like and can provide mentors for.
HTH,
Jakub
Hi Lurie,
On 04.04.2013, at 19:34, Iurie wrote:
> hello,
> in the past year gsoc qemu proposed projects there where on eproject that i liked, which were: qemu IA64 emulation : http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation
>
> this year i have not seen this project to be proposed, so i would like to know if the qemu will be selected i would like to know if i will be able to begin to make this project.
> i am also a very novice in the asm programming (so very noobish in the field, so u will have to answer a lot of noobish questions :) ), so would u accept such a student to make this project?
We had a student working on IA64 emulation last year. Typically, to get a new target working, you start off implementing Linux user space emulation, then continue to system emulation. User space emulation is a lot easier to debug, you need less features of the CPU (no MMU emulation, no privileged instructions) and you don't need device emulation code.
However, IA64 maps its virtual memory to locations that x86_64 can not map at all. Since in QEMU, Linux user emulation leverages the host's MMU to do virtual memory maps, IA64 programs can't be mapped on x86_64 hosts, which are the typical development environment for QEMU target code.
So at the end of the day, we had to cancel the IA64 emulation project last year.
There is still the slight chance to do IA64 emulation if you take the KVM IA64 code from ~3-4 years ago, forward port that to current QEMU, get the device model running with KVM on a real IA64 machine, and then implement system emulation straight on.
However, that is not an easy task. It requires quite in-depth knowledge of all the changes that happened in QEMU device models within the last years and a lot of debugging skills to get KVM working. So unless you have a lot of IA64 background, I'm afraid this is vastly out of scope for summer of code. Unfortunately.
Alex
hi,
thank you very much for the answer. i will try do some more easy projects
durring this summer related to asm and things like that and i hope in the
following year to do this project.
best regards
On 6 April 2013 10:31, Alexander Graf <email address hidden> wrote:
> Hi Lurie,
>
> On 04.04.2013, at 19:34, Iurie wrote:
>
> hello,
> in the past year gsoc qemu proposed projects there where on eproject that
> i liked, which were: qemu IA64 emulation :
> http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation
>
> this year i have not seen this project to be proposed, so i would like to
> know if the qemu will be selected i would like to know if i will be able to
> begin to make this project.
> i am also a very novice in the asm programming (so very noobish in the
> field, so u will have to answer a lot of noobish questions :) ), so would u
> accept such a student to make this project?
>
>
> We had a student working on IA64 emulation last year. Typically, to get a
> new target working, you start off implementing Linux user space emulation,
> then continue to system emulation. User space emulation is a lot easier to
> debug, you need less features of the CPU (no MMU emulation, no privileged
> instructions) and you don't need device emulation code.
>
> However, IA64 maps its virtual memory to locations that x86_64 can not map
> at all. Since in QEMU, Linux user emulation leverages the host's MMU to do
> virtual memory maps, IA64 programs can't be mapped on x86_64 hosts, which
> are the typical development environment for QEMU target code.
>
> So at the end of the day, we had to cancel the IA64 emulation project last
> year.
>
> There is still the slight chance to do IA64 emulation if you take the KVM
> IA64 code from ~3-4 years ago, forward port that to current QEMU, get the
> device model running with KVM on a real IA64 machine, and then implement
> system emulation straight on.
>
> However, that is not an easy task. It requires quite in-depth knowledge of
> all the changes that happened in QEMU device models within the last years
> and a lot of debugging skills to get KVM working. So unless you have a lot
> of IA64 background, I'm afraid this is vastly out of scope for summer of
> code. Unfortunately.
>
>
> Alex
>
>
On Sat, Apr 6, 2013 at 9:31 AM, agraf <email address hidden> wrote:
> Hi Lurie,
>
> On 04.04.2013, at 19:34, Iurie wrote:
>
>> hello,
>> in the past year gsoc qemu proposed projects there where on eproject that i liked, which were: qemu IA64 emulation : http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation
>>
>> this year i have not seen this project to be proposed, so i would like to know if the qemu will be selected i would like to know if i will be able to begin to make this project.
>> i am also a very novice in the asm programming (so very noobish in the field, so u will have to answer a lot of noobish questions :) ), so would u accept such a student to make this project?
>
> We had a student working on IA64 emulation last year. Typically, to get
> a new target working, you start off implementing Linux user space
> emulation, then continue to system emulation. User space emulation is a
> lot easier to debug, you need less features of the CPU (no MMU
> emulation, no privileged instructions) and you don't need device
> emulation code.
>
> However, IA64 maps its virtual memory to locations that x86_64 can not
> map at all. Since in QEMU, Linux user emulation leverages the host's MMU
> to do virtual memory maps, IA64 programs can't be mapped on x86_64
> hosts, which are the typical development environment for QEMU target
> code.
Out of curiosity, why doesn't GUEST_BASE help?
>
> So at the end of the day, we had to cancel the IA64 emulation project
> last year.
>
> There is still the slight chance to do IA64 emulation if you take the
> KVM IA64 code from ~3-4 years ago, forward port that to current QEMU,
> get the device model running with KVM on a real IA64 machine, and then
> implement system emulation straight on.
>
> However, that is not an easy task. It requires quite in-depth knowledge
> of all the changes that happened in QEMU device models within the last
> years and a lot of debugging skills to get KVM working. So unless you
> have a lot of IA64 background, I'm afraid this is vastly out of scope
> for summer of code. Unfortunately.
>
>
> Alex
>
> --
> You received this bug notification because you are a member of qemu-
> devel-ml, which is subscribed to QEMU.
> https://bugs.launchpad.net/bugs/1128935
>
> Title:
> MIPS r4k "TLB modified exception" generated for TLB entries that are
> not visible to the TLBP instruction
>
> Status in Home for various HelenOS development branches:
> New
> Status in QEMU:
> New
>
> Bug description:
> I occasionally see that the TLBP instruction fails to find the
> corresponding TLB entry in the TLB Modified exception handler. This
> behavior is unexpected, because the invocation of the TLB Modified
> exception suggests there indeed is such an entry in the TLB and only
> requires its dirty bit to be set.
>
> The operating system which can trigger and is susceptible to this
> behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta.
> The QEMU version on which this is reproducible is QEMU 1.4.0 and also
> some others.
>
> When I looked into the QEMU sources, I noticed the following
> discrepancy, which could potentially explain the behavior:
>
> 65 /* MIPS32/MIPS64 R4000-style MMU emulation */
> 66 int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int *prot,
> 67 target_ulong address, int rw, int access_type)
> 68 {
> <snip>
> 72 for (i = 0; i < env->tlb->tlb_in_use; i++) {
>
> 1865 void r4k_helper_tlbp(CPUMIPSState *env)
> 1866 {
> <snip>
> 1875 for (i = 0; i < env->tlb->nb_tlb; i++) {
>
> From the above it appears as if the the code which searches the TLB
> for a matching entry searched also the QEMU-specific "shadow" TLB
> entries, which is, however, not in line with how the TLBP instruction
> searches the TLB. So if a matching entry is found on index >=
> tlb_in_use, the HelenOS exception handler using TLBP to locate the
> entry would hit an assertion on seeing the Index register bit P set.
>
> I also suspect there is a similar issue with the TLB Invalid
> exception, but thanks to the specifics of the MIPS 4Kc CPU, HelenOS is
> not susceptible in this case.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/helenos/+bug/1128935/+subscriptions
>
Guys, perhaps we should move this dialogue to a different thread as we
are abusing the unrelated Bug 1128935.
Jakub
On 04/06/2013 07:01 PM, blueswirl wrote:
> On Sat, Apr 6, 2013 at 9:31 AM, agraf <email address hidden> wrote:
>> Hi Lurie,
>>
>> On 04.04.2013, at 19:34, Iurie wrote:
>>
>>> hello,
>>> in the past year gsoc qemu proposed projects there where on eproject that i liked, which were: qemu IA64 emulation : http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation
>>>
>>> this year i have not seen this project to be proposed, so i would like to know if the qemu will be selected i would like to know if i will be able to begin to make this project.
>>> i am also a very novice in the asm programming (so very noobish in the field, so u will have to answer a lot of noobish questions :) ), so would u accept such a student to make this project?
>>
>> We had a student working on IA64 emulation last year. Typically, to get
>> a new target working, you start off implementing Linux user space
>> emulation, then continue to system emulation. User space emulation is a
>> lot easier to debug, you need less features of the CPU (no MMU
>> emulation, no privileged instructions) and you don't need device
>> emulation code.
>>
>> However, IA64 maps its virtual memory to locations that x86_64 can not
>> map at all. Since in QEMU, Linux user emulation leverages the host's MMU
>> to do virtual memory maps, IA64 programs can't be mapped on x86_64
>> hosts, which are the typical development environment for QEMU target
>> code.
>
> Out of curiosity, why doesn't GUEST_BASE help?
>
>>
>> So at the end of the day, we had to cancel the IA64 emulation project
>> last year.
>>
>> There is still the slight chance to do IA64 emulation if you take the
>> KVM IA64 code from ~3-4 years ago, forward port that to current QEMU,
>> get the device model running with KVM on a real IA64 machine, and then
>> implement system emulation straight on.
>>
>> However, that is not an easy task. It requires quite in-depth knowledge
>> of all the changes that happened in QEMU device models within the last
>> years and a lot of debugging skills to get KVM working. So unless you
>> have a lot of IA64 background, I'm afraid this is vastly out of scope
>> for summer of code. Unfortunately.
>>
>>
>> Alex
>>
>> --
>> You received this bug notification because you are a member of qemu-
>> devel-ml, which is subscribed to QEMU.
>> https://bugs.launchpad.net/bugs/1128935
>>
>> Title:
>> MIPS r4k "TLB modified exception" generated for TLB entries that are
>> not visible to the TLBP instruction
>>
>> Status in Home for various HelenOS development branches:
>> New
>> Status in QEMU:
>> New
>>
>> Bug description:
>> I occasionally see that the TLBP instruction fails to find the
>> corresponding TLB entry in the TLB Modified exception handler. This
>> behavior is unexpected, because the invocation of the TLB Modified
>> exception suggests there indeed is such an entry in the TLB and only
>> requires its dirty bit to be set.
>>
>> The operating system which can trigger and is susceptible to this
>> behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta.
>> The QEMU version on which this is reproducible is QEMU 1.4.0 and also
>> some others.
>>
>> When I looked into the QEMU sources, I noticed the following
>> discrepancy, which could potentially explain the behavior:
>>
>> 65 /* MIPS32/MIPS64 R4000-style MMU emulation */
>> 66 int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int *prot,
>> 67 target_ulong address, int rw, int access_type)
>> 68 {
>> <snip>
>> 72 for (i = 0; i < env->tlb->tlb_in_use; i++) {
>>
>> 1865 void r4k_helper_tlbp(CPUMIPSState *env)
>> 1866 {
>> <snip>
>> 1875 for (i = 0; i < env->tlb->nb_tlb; i++) {
>>
>> From the above it appears as if the the code which searches the TLB
>> for a matching entry searched also the QEMU-specific "shadow" TLB
>> entries, which is, however, not in line with how the TLBP instruction
>> searches the TLB. So if a matching entry is found on index >=
>> tlb_in_use, the HelenOS exception handler using TLBP to locate the
>> entry would hit an assertion on seeing the Index register bit P set.
>>
>> I also suspect there is a similar issue with the TLB Invalid
>> exception, but thanks to the specifics of the MIPS 4Kc CPU, HelenOS is
>> not susceptible in this case.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/helenos/+bug/1128935/+subscriptions
>>
>
Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?
Yes, running the following command line with QEMU 2.11.0 on the HelenOS 0.7.1 image downloaded from http://www.helenos.org/releases/HelenOS-0.7.1-mips32-malta-be.boot will result in occasional "failures" of the TLBP instruction as described in this bug and as evidenced by a warning printed by HelenOS, which goes like:
tlb_modified: TLBP failed in exception handler (badvaddr=0x7001d7d8, ASID=29).
The command line to reproduce:
qemu-system-mips -cpu 4Kc -drive file=hdisk.img,index=0,media=disk,format=raw -device e1000,vlan=0 -net user,hostfwd=udp::8080-:8080,hostfwd=udp::8081-:8081,hostfwd=tcp::8080-:8080,hostfwd=tcp::8081-:8081,hostfwd=tcp::2223-:2223 -usb -device intel-hda -device hda-duplex -kernel HelenOS-0.7.1-mips32-malta-be.boot -nographic
It would be good if someone familiar with the mips target had a look at this.
A shorter command line to reproduce this with QEMU 2.11.0 and HelenOS 0.7.1 would be:
$ qemu-system-mips -cpu 4Kc -kernel HelenOS-0.7.1-mips32-malta-be.boot -nographic
This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:
https://gitlab.com/qemu-project/qemu/-/issues/94
|