Statistics
| Branch: | Revision:

root / qemu-tech.texi @ 5fafdf24

History | View | Annotate | Download (20.1 kB)

1
\input texinfo @c -*- texinfo -*-
2
@c %**start of header
3
@setfilename qemu-tech.info
4
@settitle QEMU Internals
5
@exampleindent 0
6
@paragraphindent 0
7
@c %**end of header
8

    
9
@iftex
10
@titlepage
11
@sp 7
12
@center @titlefont{QEMU Internals}
13
@sp 3
14
@end titlepage
15
@end iftex
16

    
17
@ifnottex
18
@node Top
19
@top
20

    
21
@menu
22
* Introduction::
23
* QEMU Internals::
24
* Regression Tests::
25
* Index::
26
@end menu
27
@end ifnottex
28

    
29
@contents
30

    
31
@node Introduction
32
@chapter Introduction
33

    
34
@menu
35
* intro_features::        Features
36
* intro_x86_emulation::   x86 emulation
37
* intro_arm_emulation::   ARM emulation
38
* intro_mips_emulation::  MIPS emulation
39
* intro_ppc_emulation::   PowerPC emulation
40
* intro_sparc_emulation:: SPARC emulation
41
@end menu
42

    
43
@node intro_features
44
@section Features
45

    
46
QEMU is a FAST! processor emulator using a portable dynamic
47
translator.
48

    
49
QEMU has two operating modes:
50

    
51
@itemize @minus
52

    
53
@item
54
Full system emulation. In this mode, QEMU emulates a full system
55
(usually a PC), including a processor and various peripherals. It can
56
be used to launch an different Operating System without rebooting the
57
PC or to debug system code.
58

    
59
@item
60
User mode emulation (Linux host only). In this mode, QEMU can launch
61
Linux processes compiled for one CPU on another CPU. It can be used to
62
launch the Wine Windows API emulator (@url{http://www.winehq.org}) or
63
to ease cross-compilation and cross-debugging.
64

    
65
@end itemize
66

    
67
As QEMU requires no host kernel driver to run, it is very safe and
68
easy to use.
69

    
70
QEMU generic features:
71

    
72
@itemize
73

    
74
@item User space only or full system emulation.
75

    
76
@item Using dynamic translation to native code for reasonable speed.
77

    
78
@item Working on x86 and PowerPC hosts. Being tested on ARM, Sparc32, Alpha and S390.
79

    
80
@item Self-modifying code support.
81

    
82
@item Precise exceptions support.
83

    
84
@item The virtual CPU is a library (@code{libqemu}) which can be used
85
in other projects (look at @file{qemu/tests/qruncom.c} to have an
86
example of user mode @code{libqemu} usage).
87

    
88
@end itemize
89

    
90
QEMU user mode emulation features:
91
@itemize
92
@item Generic Linux system call converter, including most ioctls.
93

    
94
@item clone() emulation using native CPU clone() to use Linux scheduler for threads.
95

    
96
@item Accurate signal handling by remapping host signals to target signals.
97
@end itemize
98

    
99
QEMU full system emulation features:
100
@itemize
101
@item QEMU can either use a full software MMU for maximum portability or use the host system call mmap() to simulate the target MMU.
102
@end itemize
103

    
104
@node intro_x86_emulation
105
@section x86 emulation
106

    
107
QEMU x86 target features:
108

    
109
@itemize
110

    
111
@item The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation.
112
LDT/GDT and IDT are emulated. VM86 mode is also supported to run DOSEMU.
113

    
114
@item Support of host page sizes bigger than 4KB in user mode emulation.
115

    
116
@item QEMU can emulate itself on x86.
117

    
118
@item An extensive Linux x86 CPU test program is included @file{tests/test-i386}.
119
It can be used to test other x86 virtual CPUs.
120

    
121
@end itemize
122

    
123
Current QEMU limitations:
124

    
125
@itemize
126

    
127
@item No SSE/MMX support (yet).
128

    
129
@item No x86-64 support.
130

    
131
@item IPC syscalls are missing.
132

    
133
@item The x86 segment limits and access rights are not tested at every
134
memory access (yet). Hopefully, very few OSes seem to rely on that for
135
normal use.
136

    
137
@item On non x86 host CPUs, @code{double}s are used instead of the non standard
138
10 byte @code{long double}s of x86 for floating point emulation to get
139
maximum performances.
140

    
141
@end itemize
142

    
143
@node intro_arm_emulation
144
@section ARM emulation
145

    
146
@itemize
147

    
148
@item Full ARM 7 user emulation.
149

    
150
@item NWFPE FPU support included in user Linux emulation.
151

    
152
@item Can run most ARM Linux binaries.
153

    
154
@end itemize
155

    
156
@node intro_mips_emulation
157
@section MIPS emulation
158

    
159
@itemize
160

    
161
@item The system emulation allows full MIPS32/MIPS64 Release 2 emulation,
162
including privileged instructions, FPU and MMU, in both little and big
163
endian modes.
164

    
165
@item The Linux userland emulation can run many 32 bit MIPS Linux binaries.
166

    
167
@end itemize
168

    
169
Current QEMU limitations:
170

    
171
@itemize
172

    
173
@item Self-modifying code is not always handled correctly.
174

    
175
@item 64 bit userland emulation is not implemented.
176

    
177
@item The system emulation is not complete enough to run real firmware.
178

    
179
@item The watchpoint debug facility is not implemented.
180

    
181
@end itemize
182

    
183
@node intro_ppc_emulation
184
@section PowerPC emulation
185

    
186
@itemize
187

    
188
@item Full PowerPC 32 bit emulation, including privileged instructions,
189
FPU and MMU.
190

    
191
@item Can run most PowerPC Linux binaries.
192

    
193
@end itemize
194

    
195
@node intro_sparc_emulation
196
@section SPARC emulation
197

    
198
@itemize
199

    
200
@item Full SPARC V8 emulation, including privileged
201
instructions, FPU and MMU. SPARC V9 emulation includes most privileged
202
instructions, FPU and I/D MMU, but misses most VIS instructions.
203

    
204
@item Can run most 32-bit SPARC Linux binaries and some handcrafted 64-bit SPARC Linux binaries.
205

    
206
@end itemize
207

    
208
Current QEMU limitations:
209

    
210
@itemize
211

    
212
@item IPC syscalls are missing.
213

    
214
@item 128-bit floating point operations are not supported, though none of the
215
real CPUs implement them either. FCMPE[SD] are not correctly
216
implemented.  Floating point exception support is untested.
217

    
218
@item Alignment is not enforced at all.
219

    
220
@item Atomic instructions are not correctly implemented.
221

    
222
@item Sparc64 emulators are not usable for anything yet.
223

    
224
@end itemize
225

    
226
@node QEMU Internals
227
@chapter QEMU Internals
228

    
229
@menu
230
* QEMU compared to other emulators::
231
* Portable dynamic translation::
232
* Register allocation::
233
* Condition code optimisations::
234
* CPU state optimisations::
235
* Translation cache::
236
* Direct block chaining::
237
* Self-modifying code and translated code invalidation::
238
* Exception support::
239
* MMU emulation::
240
* Hardware interrupts::
241
* User emulation specific details::
242
* Bibliography::
243
@end menu
244

    
245
@node QEMU compared to other emulators
246
@section QEMU compared to other emulators
247

    
248
Like bochs [3], QEMU emulates an x86 CPU. But QEMU is much faster than
249
bochs as it uses dynamic compilation. Bochs is closely tied to x86 PC
250
emulation while QEMU can emulate several processors.
251

    
252
Like Valgrind [2], QEMU does user space emulation and dynamic
253
translation. Valgrind is mainly a memory debugger while QEMU has no
254
support for it (QEMU could be used to detect out of bound memory
255
accesses as Valgrind, but it has no support to track uninitialised data
256
as Valgrind does). The Valgrind dynamic translator generates better code
257
than QEMU (in particular it does register allocation) but it is closely
258
tied to an x86 host and target and has no support for precise exceptions
259
and system emulation.
260

    
261
EM86 [4] is the closest project to user space QEMU (and QEMU still uses
262
some of its code, in particular the ELF file loader). EM86 was limited
263
to an alpha host and used a proprietary and slow interpreter (the
264
interpreter part of the FX!32 Digital Win32 code translator [5]).
265

    
266
TWIN [6] is a Windows API emulator like Wine. It is less accurate than
267
Wine but includes a protected mode x86 interpreter to launch x86 Windows
268
executables. Such an approach has greater potential because most of the
269
Windows API is executed natively but it is far more difficult to develop
270
because all the data structures and function parameters exchanged
271
between the API and the x86 code must be converted.
272

    
273
User mode Linux [7] was the only solution before QEMU to launch a
274
Linux kernel as a process while not needing any host kernel
275
patches. However, user mode Linux requires heavy kernel patches while
276
QEMU accepts unpatched Linux kernels. The price to pay is that QEMU is
277
slower.
278

    
279
The new Plex86 [8] PC virtualizer is done in the same spirit as the
280
qemu-fast system emulator. It requires a patched Linux kernel to work
281
(you cannot launch the same kernel on your PC), but the patches are
282
really small. As it is a PC virtualizer (no emulation is done except
283
for some priveledged instructions), it has the potential of being
284
faster than QEMU. The downside is that a complicated (and potentially
285
unsafe) host kernel patch is needed.
286

    
287
The commercial PC Virtualizers (VMWare [9], VirtualPC [10], TwoOStwo
288
[11]) are faster than QEMU, but they all need specific, proprietary
289
and potentially unsafe host drivers. Moreover, they are unable to
290
provide cycle exact simulation as an emulator can.
291

    
292
@node Portable dynamic translation
293
@section Portable dynamic translation
294

    
295
QEMU is a dynamic translator. When it first encounters a piece of code,
296
it converts it to the host instruction set. Usually dynamic translators
297
are very complicated and highly CPU dependent. QEMU uses some tricks
298
which make it relatively easily portable and simple while achieving good
299
performances.
300

    
301
The basic idea is to split every x86 instruction into fewer simpler
302
instructions. Each simple instruction is implemented by a piece of C
303
code (see @file{target-i386/op.c}). Then a compile time tool
304
(@file{dyngen}) takes the corresponding object file (@file{op.o})
305
to generate a dynamic code generator which concatenates the simple
306
instructions to build a function (see @file{op.h:dyngen_code()}).
307

    
308
In essence, the process is similar to [1], but more work is done at
309
compile time.
310

    
311
A key idea to get optimal performances is that constant parameters can
312
be passed to the simple operations. For that purpose, dummy ELF
313
relocations are generated with gcc for each constant parameter. Then,
314
the tool (@file{dyngen}) can locate the relocations and generate the
315
appriopriate C code to resolve them when building the dynamic code.
316

    
317
That way, QEMU is no more difficult to port than a dynamic linker.
318

    
319
To go even faster, GCC static register variables are used to keep the
320
state of the virtual CPU.
321

    
322
@node Register allocation
323
@section Register allocation
324

    
325
Since QEMU uses fixed simple instructions, no efficient register
326
allocation can be done. However, because RISC CPUs have a lot of
327
register, most of the virtual CPU state can be put in registers without
328
doing complicated register allocation.
329

    
330
@node Condition code optimisations
331
@section Condition code optimisations
332

    
333
Good CPU condition codes emulation (@code{EFLAGS} register on x86) is a
334
critical point to get good performances. QEMU uses lazy condition code
335
evaluation: instead of computing the condition codes after each x86
336
instruction, it just stores one operand (called @code{CC_SRC}), the
337
result (called @code{CC_DST}) and the type of operation (called
338
@code{CC_OP}).
339

    
340
@code{CC_OP} is almost never explicitely set in the generated code
341
because it is known at translation time.
342

    
343
In order to increase performances, a backward pass is performed on the
344
generated simple instructions (see
345
@code{target-i386/translate.c:optimize_flags()}). When it can be proved that
346
the condition codes are not needed by the next instructions, no
347
condition codes are computed at all.
348

    
349
@node CPU state optimisations
350
@section CPU state optimisations
351

    
352
The x86 CPU has many internal states which change the way it evaluates
353
instructions. In order to achieve a good speed, the translation phase
354
considers that some state information of the virtual x86 CPU cannot
355
change in it. For example, if the SS, DS and ES segments have a zero
356
base, then the translator does not even generate an addition for the
357
segment base.
358

    
359
[The FPU stack pointer register is not handled that way yet].
360

    
361
@node Translation cache
362
@section Translation cache
363

    
364
A 16 MByte cache holds the most recently used translations. For
365
simplicity, it is completely flushed when it is full. A translation unit
366
contains just a single basic block (a block of x86 instructions
367
terminated by a jump or by a virtual CPU state change which the
368
translator cannot deduce statically).
369

    
370
@node Direct block chaining
371
@section Direct block chaining
372

    
373
After each translated basic block is executed, QEMU uses the simulated
374
Program Counter (PC) and other cpu state informations (such as the CS
375
segment base value) to find the next basic block.
376

    
377
In order to accelerate the most common cases where the new simulated PC
378
is known, QEMU can patch a basic block so that it jumps directly to the
379
next one.
380

    
381
The most portable code uses an indirect jump. An indirect jump makes
382
it easier to make the jump target modification atomic. On some host
383
architectures (such as x86 or PowerPC), the @code{JUMP} opcode is
384
directly patched so that the block chaining has no overhead.
385

    
386
@node Self-modifying code and translated code invalidation
387
@section Self-modifying code and translated code invalidation
388

    
389
Self-modifying code is a special challenge in x86 emulation because no
390
instruction cache invalidation is signaled by the application when code
391
is modified.
392

    
393
When translated code is generated for a basic block, the corresponding
394
host page is write protected if it is not already read-only (with the
395
system call @code{mprotect()}). Then, if a write access is done to the
396
page, Linux raises a SEGV signal. QEMU then invalidates all the
397
translated code in the page and enables write accesses to the page.
398

    
399
Correct translated code invalidation is done efficiently by maintaining
400
a linked list of every translated block contained in a given page. Other
401
linked lists are also maintained to undo direct block chaining.
402

    
403
Although the overhead of doing @code{mprotect()} calls is important,
404
most MSDOS programs can be emulated at reasonnable speed with QEMU and
405
DOSEMU.
406

    
407
Note that QEMU also invalidates pages of translated code when it detects
408
that memory mappings are modified with @code{mmap()} or @code{munmap()}.
409

    
410
When using a software MMU, the code invalidation is more efficient: if
411
a given code page is invalidated too often because of write accesses,
412
then a bitmap representing all the code inside the page is
413
built. Every store into that page checks the bitmap to see if the code
414
really needs to be invalidated. It avoids invalidating the code when
415
only data is modified in the page.
416

    
417
@node Exception support
418
@section Exception support
419

    
420
longjmp() is used when an exception such as division by zero is
421
encountered.
422

    
423
The host SIGSEGV and SIGBUS signal handlers are used to get invalid
424
memory accesses. The exact CPU state can be retrieved because all the
425
x86 registers are stored in fixed host registers. The simulated program
426
counter is found by retranslating the corresponding basic block and by
427
looking where the host program counter was at the exception point.
428

    
429
The virtual CPU cannot retrieve the exact @code{EFLAGS} register because
430
in some cases it is not computed because of condition code
431
optimisations. It is not a big concern because the emulated code can
432
still be restarted in any cases.
433

    
434
@node MMU emulation
435
@section MMU emulation
436

    
437
For system emulation, QEMU uses the mmap() system call to emulate the
438
target CPU MMU. It works as long the emulated OS does not use an area
439
reserved by the host OS (such as the area above 0xc0000000 on x86
440
Linux).
441

    
442
In order to be able to launch any OS, QEMU also supports a soft
443
MMU. In that mode, the MMU virtual to physical address translation is
444
done at every memory access. QEMU uses an address translation cache to
445
speed up the translation.
446

    
447
In order to avoid flushing the translated code each time the MMU
448
mappings change, QEMU uses a physically indexed translation cache. It
449
means that each basic block is indexed with its physical address.
450

    
451
When MMU mappings change, only the chaining of the basic blocks is
452
reset (i.e. a basic block can no longer jump directly to another one).
453

    
454
@node Hardware interrupts
455
@section Hardware interrupts
456

    
457
In order to be faster, QEMU does not check at every basic block if an
458
hardware interrupt is pending. Instead, the user must asynchrously
459
call a specific function to tell that an interrupt is pending. This
460
function resets the chaining of the currently executing basic
461
block. It ensures that the execution will return soon in the main loop
462
of the CPU emulator. Then the main loop can test if the interrupt is
463
pending and handle it.
464

    
465
@node User emulation specific details
466
@section User emulation specific details
467

    
468
@subsection Linux system call translation
469

    
470
QEMU includes a generic system call translator for Linux. It means that
471
the parameters of the system calls can be converted to fix the
472
endianness and 32/64 bit issues. The IOCTLs are converted with a generic
473
type description system (see @file{ioctls.h} and @file{thunk.c}).
474

    
475
QEMU supports host CPUs which have pages bigger than 4KB. It records all
476
the mappings the process does and try to emulated the @code{mmap()}
477
system calls in cases where the host @code{mmap()} call would fail
478
because of bad page alignment.
479

    
480
@subsection Linux signals
481

    
482
Normal and real-time signals are queued along with their information
483
(@code{siginfo_t}) as it is done in the Linux kernel. Then an interrupt
484
request is done to the virtual CPU. When it is interrupted, one queued
485
signal is handled by generating a stack frame in the virtual CPU as the
486
Linux kernel does. The @code{sigreturn()} system call is emulated to return
487
from the virtual signal handler.
488

    
489
Some signals (such as SIGALRM) directly come from the host. Other
490
signals are synthetized from the virtual CPU exceptions such as SIGFPE
491
when a division by zero is done (see @code{main.c:cpu_loop()}).
492

    
493
The blocked signal mask is still handled by the host Linux kernel so
494
that most signal system calls can be redirected directly to the host
495
Linux kernel. Only the @code{sigaction()} and @code{sigreturn()} system
496
calls need to be fully emulated (see @file{signal.c}).
497

    
498
@subsection clone() system call and threads
499

    
500
The Linux clone() system call is usually used to create a thread. QEMU
501
uses the host clone() system call so that real host threads are created
502
for each emulated thread. One virtual CPU instance is created for each
503
thread.
504

    
505
The virtual x86 CPU atomic operations are emulated with a global lock so
506
that their semantic is preserved.
507

    
508
Note that currently there are still some locking issues in QEMU. In
509
particular, the translated cache flush is not protected yet against
510
reentrancy.
511

    
512
@subsection Self-virtualization
513

    
514
QEMU was conceived so that ultimately it can emulate itself. Although
515
it is not very useful, it is an important test to show the power of the
516
emulator.
517

    
518
Achieving self-virtualization is not easy because there may be address
519
space conflicts. QEMU solves this problem by being an executable ELF
520
shared object as the ld-linux.so ELF interpreter. That way, it can be
521
relocated at load time.
522

    
523
@node Bibliography
524
@section Bibliography
525

    
526
@table @asis
527

    
528
@item [1]
529
@url{http://citeseer.nj.nec.com/piumarta98optimizing.html}, Optimizing
530
direct threaded code by selective inlining (1998) by Ian Piumarta, Fabio
531
Riccardi.
532

    
533
@item [2]
534
@url{http://developer.kde.org/~sewardj/}, Valgrind, an open-source
535
memory debugger for x86-GNU/Linux, by Julian Seward.
536

    
537
@item [3]
538
@url{http://bochs.sourceforge.net/}, the Bochs IA-32 Emulator Project,
539
by Kevin Lawton et al.
540

    
541
@item [4]
542
@url{http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html}, the EM86
543
x86 emulator on Alpha-Linux.
544

    
545
@item [5]
546
@url{http://www.usenix.org/publications/library/proceedings/usenix-nt97/@/full_papers/chernoff/chernoff.pdf},
547
DIGITAL FX!32: Running 32-Bit x86 Applications on Alpha NT, by Anton
548
Chernoff and Ray Hookway.
549

    
550
@item [6]
551
@url{http://www.willows.com/}, Windows API library emulation from
552
Willows Software.
553

    
554
@item [7]
555
@url{http://user-mode-linux.sourceforge.net/},
556
The User-mode Linux Kernel.
557

    
558
@item [8]
559
@url{http://www.plex86.org/},
560
The new Plex86 project.
561

    
562
@item [9]
563
@url{http://www.vmware.com/},
564
The VMWare PC virtualizer.
565

    
566
@item [10]
567
@url{http://www.microsoft.com/windowsxp/virtualpc/},
568
The VirtualPC PC virtualizer.
569

    
570
@item [11]
571
@url{http://www.twoostwo.org/},
572
The TwoOStwo PC virtualizer.
573

    
574
@end table
575

    
576
@node Regression Tests
577
@chapter Regression Tests
578

    
579
In the directory @file{tests/}, various interesting testing programs
580
are available. They are used for regression testing.
581

    
582
@menu
583
* test-i386::
584
* linux-test::
585
* qruncom.c::
586
@end menu
587

    
588
@node test-i386
589
@section @file{test-i386}
590

    
591
This program executes most of the 16 bit and 32 bit x86 instructions and
592
generates a text output. It can be compared with the output obtained with
593
a real CPU or another emulator. The target @code{make test} runs this
594
program and a @code{diff} on the generated output.
595

    
596
The Linux system call @code{modify_ldt()} is used to create x86 selectors
597
to test some 16 bit addressing and 32 bit with segmentation cases.
598

    
599
The Linux system call @code{vm86()} is used to test vm86 emulation.
600

    
601
Various exceptions are raised to test most of the x86 user space
602
exception reporting.
603

    
604
@node linux-test
605
@section @file{linux-test}
606

    
607
This program tests various Linux system calls. It is used to verify
608
that the system call parameters are correctly converted between target
609
and host CPUs.
610

    
611
@node qruncom.c
612
@section @file{qruncom.c}
613

    
614
Example of usage of @code{libqemu} to emulate a user mode i386 CPU.
615

    
616
@node Index
617
@chapter Index
618
@printindex cp
619

    
620
@bye