root / qemu-tech.texi @ 39bffca2
History | View | Annotate | Download (23 kB)
1 |
\input texinfo @c -*- texinfo -*- |
---|---|
2 |
@c %**start of header |
3 |
@setfilename qemu-tech.info |
4 |
|
5 |
@documentlanguage en |
6 |
@documentencoding UTF-8 |
7 |
|
8 |
@settitle QEMU Internals |
9 |
@exampleindent 0 |
10 |
@paragraphindent 0 |
11 |
@c %**end of header |
12 |
|
13 |
@ifinfo |
14 |
@direntry |
15 |
* QEMU Internals: (qemu-tech). The QEMU Emulator Internals. |
16 |
@end direntry |
17 |
@end ifinfo |
18 |
|
19 |
@iftex |
20 |
@titlepage |
21 |
@sp 7 |
22 |
@center @titlefont{QEMU Internals} |
23 |
@sp 3 |
24 |
@end titlepage |
25 |
@end iftex |
26 |
|
27 |
@ifnottex |
28 |
@node Top |
29 |
@top |
30 |
|
31 |
@menu |
32 |
* Introduction:: |
33 |
* QEMU Internals:: |
34 |
* Regression Tests:: |
35 |
* Index:: |
36 |
@end menu |
37 |
@end ifnottex |
38 |
|
39 |
@contents |
40 |
|
41 |
@node Introduction |
42 |
@chapter Introduction |
43 |
|
44 |
@menu |
45 |
* intro_features:: Features |
46 |
* intro_x86_emulation:: x86 and x86-64 emulation |
47 |
* intro_arm_emulation:: ARM emulation |
48 |
* intro_mips_emulation:: MIPS emulation |
49 |
* intro_ppc_emulation:: PowerPC emulation |
50 |
* intro_sparc_emulation:: Sparc32 and Sparc64 emulation |
51 |
* intro_xtensa_emulation:: Xtensa emulation |
52 |
* intro_other_emulation:: Other CPU emulation |
53 |
@end menu |
54 |
|
55 |
@node intro_features |
56 |
@section Features |
57 |
|
58 |
QEMU is a FAST! processor emulator using a portable dynamic |
59 |
translator. |
60 |
|
61 |
QEMU has two operating modes: |
62 |
|
63 |
@itemize @minus |
64 |
|
65 |
@item |
66 |
Full system emulation. In this mode (full platform virtualization), |
67 |
QEMU emulates a full system (usually a PC), including a processor and |
68 |
various peripherals. It can be used to launch several different |
69 |
Operating Systems at once without rebooting the host machine or to |
70 |
debug system code. |
71 |
|
72 |
@item |
73 |
User mode emulation. In this mode (application level virtualization), |
74 |
QEMU can launch processes compiled for one CPU on another CPU, however |
75 |
the Operating Systems must match. This can be used for example to ease |
76 |
cross-compilation and cross-debugging. |
77 |
@end itemize |
78 |
|
79 |
As QEMU requires no host kernel driver to run, it is very safe and |
80 |
easy to use. |
81 |
|
82 |
QEMU generic features: |
83 |
|
84 |
@itemize |
85 |
|
86 |
@item User space only or full system emulation. |
87 |
|
88 |
@item Using dynamic translation to native code for reasonable speed. |
89 |
|
90 |
@item |
91 |
Working on x86, x86_64 and PowerPC32/64 hosts. Being tested on ARM, |
92 |
HPPA, Sparc32 and Sparc64. Previous versions had some support for |
93 |
Alpha and S390 hosts, but TCG (see below) doesn't support those yet. |
94 |
|
95 |
@item Self-modifying code support. |
96 |
|
97 |
@item Precise exceptions support. |
98 |
|
99 |
@item |
100 |
Floating point library supporting both full software emulation and |
101 |
native host FPU instructions. |
102 |
|
103 |
@end itemize |
104 |
|
105 |
QEMU user mode emulation features: |
106 |
@itemize |
107 |
@item Generic Linux system call converter, including most ioctls. |
108 |
|
109 |
@item clone() emulation using native CPU clone() to use Linux scheduler for threads. |
110 |
|
111 |
@item Accurate signal handling by remapping host signals to target signals. |
112 |
@end itemize |
113 |
|
114 |
Linux user emulator (Linux host only) can be used to launch the Wine |
115 |
Windows API emulator (@url{http://www.winehq.org}). A Darwin user |
116 |
emulator (Darwin hosts only) exists and a BSD user emulator for BSD |
117 |
hosts is under development. It would also be possible to develop a |
118 |
similar user emulator for Solaris. |
119 |
|
120 |
QEMU full system emulation features: |
121 |
@itemize |
122 |
@item |
123 |
QEMU uses a full software MMU for maximum portability. |
124 |
|
125 |
@item |
126 |
QEMU can optionally use an in-kernel accelerator, like kvm. The accelerators |
127 |
execute some of the guest code natively, while |
128 |
continuing to emulate the rest of the machine. |
129 |
|
130 |
@item |
131 |
Various hardware devices can be emulated and in some cases, host |
132 |
devices (e.g. serial and parallel ports, USB, drives) can be used |
133 |
transparently by the guest Operating System. Host device passthrough |
134 |
can be used for talking to external physical peripherals (e.g. a |
135 |
webcam, modem or tape drive). |
136 |
|
137 |
@item |
138 |
Symmetric multiprocessing (SMP) even on a host with a single CPU. On a |
139 |
SMP host system, QEMU can use only one CPU fully due to difficulty in |
140 |
implementing atomic memory accesses efficiently. |
141 |
|
142 |
@end itemize |
143 |
|
144 |
@node intro_x86_emulation |
145 |
@section x86 and x86-64 emulation |
146 |
|
147 |
QEMU x86 target features: |
148 |
|
149 |
@itemize |
150 |
|
151 |
@item The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation. |
152 |
LDT/GDT and IDT are emulated. VM86 mode is also supported to run |
153 |
DOSEMU. There is some support for MMX/3DNow!, SSE, SSE2, SSE3, SSSE3, |
154 |
and SSE4 as well as x86-64 SVM. |
155 |
|
156 |
@item Support of host page sizes bigger than 4KB in user mode emulation. |
157 |
|
158 |
@item QEMU can emulate itself on x86. |
159 |
|
160 |
@item An extensive Linux x86 CPU test program is included @file{tests/test-i386}. |
161 |
It can be used to test other x86 virtual CPUs. |
162 |
|
163 |
@end itemize |
164 |
|
165 |
Current QEMU limitations: |
166 |
|
167 |
@itemize |
168 |
|
169 |
@item Limited x86-64 support. |
170 |
|
171 |
@item IPC syscalls are missing. |
172 |
|
173 |
@item The x86 segment limits and access rights are not tested at every |
174 |
memory access (yet). Hopefully, very few OSes seem to rely on that for |
175 |
normal use. |
176 |
|
177 |
@end itemize |
178 |
|
179 |
@node intro_arm_emulation |
180 |
@section ARM emulation |
181 |
|
182 |
@itemize |
183 |
|
184 |
@item Full ARM 7 user emulation. |
185 |
|
186 |
@item NWFPE FPU support included in user Linux emulation. |
187 |
|
188 |
@item Can run most ARM Linux binaries. |
189 |
|
190 |
@end itemize |
191 |
|
192 |
@node intro_mips_emulation |
193 |
@section MIPS emulation |
194 |
|
195 |
@itemize |
196 |
|
197 |
@item The system emulation allows full MIPS32/MIPS64 Release 2 emulation, |
198 |
including privileged instructions, FPU and MMU, in both little and big |
199 |
endian modes. |
200 |
|
201 |
@item The Linux userland emulation can run many 32 bit MIPS Linux binaries. |
202 |
|
203 |
@end itemize |
204 |
|
205 |
Current QEMU limitations: |
206 |
|
207 |
@itemize |
208 |
|
209 |
@item Self-modifying code is not always handled correctly. |
210 |
|
211 |
@item 64 bit userland emulation is not implemented. |
212 |
|
213 |
@item The system emulation is not complete enough to run real firmware. |
214 |
|
215 |
@item The watchpoint debug facility is not implemented. |
216 |
|
217 |
@end itemize |
218 |
|
219 |
@node intro_ppc_emulation |
220 |
@section PowerPC emulation |
221 |
|
222 |
@itemize |
223 |
|
224 |
@item Full PowerPC 32 bit emulation, including privileged instructions, |
225 |
FPU and MMU. |
226 |
|
227 |
@item Can run most PowerPC Linux binaries. |
228 |
|
229 |
@end itemize |
230 |
|
231 |
@node intro_sparc_emulation |
232 |
@section Sparc32 and Sparc64 emulation |
233 |
|
234 |
@itemize |
235 |
|
236 |
@item Full SPARC V8 emulation, including privileged |
237 |
instructions, FPU and MMU. SPARC V9 emulation includes most privileged |
238 |
and VIS instructions, FPU and I/D MMU. Alignment is fully enforced. |
239 |
|
240 |
@item Can run most 32-bit SPARC Linux binaries, SPARC32PLUS Linux binaries and |
241 |
some 64-bit SPARC Linux binaries. |
242 |
|
243 |
@end itemize |
244 |
|
245 |
Current QEMU limitations: |
246 |
|
247 |
@itemize |
248 |
|
249 |
@item IPC syscalls are missing. |
250 |
|
251 |
@item Floating point exception support is buggy. |
252 |
|
253 |
@item Atomic instructions are not correctly implemented. |
254 |
|
255 |
@item There are still some problems with Sparc64 emulators. |
256 |
|
257 |
@end itemize |
258 |
|
259 |
@node intro_xtensa_emulation |
260 |
@section Xtensa emulation |
261 |
|
262 |
@itemize |
263 |
|
264 |
@item Core Xtensa ISA emulation, including most options: code density, |
265 |
loop, extended L32R, 16- and 32-bit multiplication, 32-bit division, |
266 |
MAC16, miscellaneous operations, boolean, multiprocessor synchronization, |
267 |
conditional store, exceptions, relocatable vectors, unaligned exception, |
268 |
interrupts (including high priority and timer), hardware alignment, |
269 |
region protection, region translation, MMU, windowed registers, thread |
270 |
pointer, processor ID. |
271 |
|
272 |
@item Not implemented options: FP coprocessor, coprocessor context, |
273 |
data/instruction cache (including cache prefetch and locking), XLMI, |
274 |
processor interface, debug. Also options not covered by the core ISA |
275 |
(e.g. FLIX, wide branches) are not implemented. |
276 |
|
277 |
@item Can run most Xtensa Linux binaries. |
278 |
|
279 |
@item New core configuration that requires no additional instructions |
280 |
may be created from overlay with minimal amount of hand-written code. |
281 |
|
282 |
@end itemize |
283 |
|
284 |
@node intro_other_emulation |
285 |
@section Other CPU emulation |
286 |
|
287 |
In addition to the above, QEMU supports emulation of other CPUs with |
288 |
varying levels of success. These are: |
289 |
|
290 |
@itemize |
291 |
|
292 |
@item |
293 |
Alpha |
294 |
@item |
295 |
CRIS |
296 |
@item |
297 |
M68k |
298 |
@item |
299 |
SH4 |
300 |
@end itemize |
301 |
|
302 |
@node QEMU Internals |
303 |
@chapter QEMU Internals |
304 |
|
305 |
@menu |
306 |
* QEMU compared to other emulators:: |
307 |
* Portable dynamic translation:: |
308 |
* Condition code optimisations:: |
309 |
* CPU state optimisations:: |
310 |
* Translation cache:: |
311 |
* Direct block chaining:: |
312 |
* Self-modifying code and translated code invalidation:: |
313 |
* Exception support:: |
314 |
* MMU emulation:: |
315 |
* Device emulation:: |
316 |
* Hardware interrupts:: |
317 |
* User emulation specific details:: |
318 |
* Bibliography:: |
319 |
@end menu |
320 |
|
321 |
@node QEMU compared to other emulators |
322 |
@section QEMU compared to other emulators |
323 |
|
324 |
Like bochs [3], QEMU emulates an x86 CPU. But QEMU is much faster than |
325 |
bochs as it uses dynamic compilation. Bochs is closely tied to x86 PC |
326 |
emulation while QEMU can emulate several processors. |
327 |
|
328 |
Like Valgrind [2], QEMU does user space emulation and dynamic |
329 |
translation. Valgrind is mainly a memory debugger while QEMU has no |
330 |
support for it (QEMU could be used to detect out of bound memory |
331 |
accesses as Valgrind, but it has no support to track uninitialised data |
332 |
as Valgrind does). The Valgrind dynamic translator generates better code |
333 |
than QEMU (in particular it does register allocation) but it is closely |
334 |
tied to an x86 host and target and has no support for precise exceptions |
335 |
and system emulation. |
336 |
|
337 |
EM86 [4] is the closest project to user space QEMU (and QEMU still uses |
338 |
some of its code, in particular the ELF file loader). EM86 was limited |
339 |
to an alpha host and used a proprietary and slow interpreter (the |
340 |
interpreter part of the FX!32 Digital Win32 code translator [5]). |
341 |
|
342 |
TWIN [6] is a Windows API emulator like Wine. It is less accurate than |
343 |
Wine but includes a protected mode x86 interpreter to launch x86 Windows |
344 |
executables. Such an approach has greater potential because most of the |
345 |
Windows API is executed natively but it is far more difficult to develop |
346 |
because all the data structures and function parameters exchanged |
347 |
between the API and the x86 code must be converted. |
348 |
|
349 |
User mode Linux [7] was the only solution before QEMU to launch a |
350 |
Linux kernel as a process while not needing any host kernel |
351 |
patches. However, user mode Linux requires heavy kernel patches while |
352 |
QEMU accepts unpatched Linux kernels. The price to pay is that QEMU is |
353 |
slower. |
354 |
|
355 |
The Plex86 [8] PC virtualizer is done in the same spirit as the now |
356 |
obsolete qemu-fast system emulator. It requires a patched Linux kernel |
357 |
to work (you cannot launch the same kernel on your PC), but the |
358 |
patches are really small. As it is a PC virtualizer (no emulation is |
359 |
done except for some privileged instructions), it has the potential of |
360 |
being faster than QEMU. The downside is that a complicated (and |
361 |
potentially unsafe) host kernel patch is needed. |
362 |
|
363 |
The commercial PC Virtualizers (VMWare [9], VirtualPC [10], TwoOStwo |
364 |
[11]) are faster than QEMU, but they all need specific, proprietary |
365 |
and potentially unsafe host drivers. Moreover, they are unable to |
366 |
provide cycle exact simulation as an emulator can. |
367 |
|
368 |
VirtualBox [12], Xen [13] and KVM [14] are based on QEMU. QEMU-SystemC |
369 |
[15] uses QEMU to simulate a system where some hardware devices are |
370 |
developed in SystemC. |
371 |
|
372 |
@node Portable dynamic translation |
373 |
@section Portable dynamic translation |
374 |
|
375 |
QEMU is a dynamic translator. When it first encounters a piece of code, |
376 |
it converts it to the host instruction set. Usually dynamic translators |
377 |
are very complicated and highly CPU dependent. QEMU uses some tricks |
378 |
which make it relatively easily portable and simple while achieving good |
379 |
performances. |
380 |
|
381 |
After the release of version 0.9.1, QEMU switched to a new method of |
382 |
generating code, Tiny Code Generator or TCG. TCG relaxes the |
383 |
dependency on the exact version of the compiler used. The basic idea |
384 |
is to split every target instruction into a couple of RISC-like TCG |
385 |
ops (see @code{target-i386/translate.c}). Some optimizations can be |
386 |
performed at this stage, including liveness analysis and trivial |
387 |
constant expression evaluation. TCG ops are then implemented in the |
388 |
host CPU back end, also known as TCG target (see |
389 |
@code{tcg/i386/tcg-target.c}). For more information, please take a |
390 |
look at @code{tcg/README}. |
391 |
|
392 |
@node Condition code optimisations |
393 |
@section Condition code optimisations |
394 |
|
395 |
Lazy evaluation of CPU condition codes (@code{EFLAGS} register on x86) |
396 |
is important for CPUs where every instruction sets the condition |
397 |
codes. It tends to be less important on conventional RISC systems |
398 |
where condition codes are only updated when explicitly requested. On |
399 |
Sparc64, costly update of both 32 and 64 bit condition codes can be |
400 |
avoided with lazy evaluation. |
401 |
|
402 |
Instead of computing the condition codes after each x86 instruction, |
403 |
QEMU just stores one operand (called @code{CC_SRC}), the result |
404 |
(called @code{CC_DST}) and the type of operation (called |
405 |
@code{CC_OP}). When the condition codes are needed, the condition |
406 |
codes can be calculated using this information. In addition, an |
407 |
optimized calculation can be performed for some instruction types like |
408 |
conditional branches. |
409 |
|
410 |
@code{CC_OP} is almost never explicitly set in the generated code |
411 |
because it is known at translation time. |
412 |
|
413 |
The lazy condition code evaluation is used on x86, m68k, cris and |
414 |
Sparc. ARM uses a simplified variant for the N and Z flags. |
415 |
|
416 |
@node CPU state optimisations |
417 |
@section CPU state optimisations |
418 |
|
419 |
The target CPUs have many internal states which change the way it |
420 |
evaluates instructions. In order to achieve a good speed, the |
421 |
translation phase considers that some state information of the virtual |
422 |
CPU cannot change in it. The state is recorded in the Translation |
423 |
Block (TB). If the state changes (e.g. privilege level), a new TB will |
424 |
be generated and the previous TB won't be used anymore until the state |
425 |
matches the state recorded in the previous TB. For example, if the SS, |
426 |
DS and ES segments have a zero base, then the translator does not even |
427 |
generate an addition for the segment base. |
428 |
|
429 |
[The FPU stack pointer register is not handled that way yet]. |
430 |
|
431 |
@node Translation cache |
432 |
@section Translation cache |
433 |
|
434 |
A 32 MByte cache holds the most recently used translations. For |
435 |
simplicity, it is completely flushed when it is full. A translation unit |
436 |
contains just a single basic block (a block of x86 instructions |
437 |
terminated by a jump or by a virtual CPU state change which the |
438 |
translator cannot deduce statically). |
439 |
|
440 |
@node Direct block chaining |
441 |
@section Direct block chaining |
442 |
|
443 |
After each translated basic block is executed, QEMU uses the simulated |
444 |
Program Counter (PC) and other cpu state informations (such as the CS |
445 |
segment base value) to find the next basic block. |
446 |
|
447 |
In order to accelerate the most common cases where the new simulated PC |
448 |
is known, QEMU can patch a basic block so that it jumps directly to the |
449 |
next one. |
450 |
|
451 |
The most portable code uses an indirect jump. An indirect jump makes |
452 |
it easier to make the jump target modification atomic. On some host |
453 |
architectures (such as x86 or PowerPC), the @code{JUMP} opcode is |
454 |
directly patched so that the block chaining has no overhead. |
455 |
|
456 |
@node Self-modifying code and translated code invalidation |
457 |
@section Self-modifying code and translated code invalidation |
458 |
|
459 |
Self-modifying code is a special challenge in x86 emulation because no |
460 |
instruction cache invalidation is signaled by the application when code |
461 |
is modified. |
462 |
|
463 |
When translated code is generated for a basic block, the corresponding |
464 |
host page is write protected if it is not already read-only. Then, if |
465 |
a write access is done to the page, Linux raises a SEGV signal. QEMU |
466 |
then invalidates all the translated code in the page and enables write |
467 |
accesses to the page. |
468 |
|
469 |
Correct translated code invalidation is done efficiently by maintaining |
470 |
a linked list of every translated block contained in a given page. Other |
471 |
linked lists are also maintained to undo direct block chaining. |
472 |
|
473 |
On RISC targets, correctly written software uses memory barriers and |
474 |
cache flushes, so some of the protection above would not be |
475 |
necessary. However, QEMU still requires that the generated code always |
476 |
matches the target instructions in memory in order to handle |
477 |
exceptions correctly. |
478 |
|
479 |
@node Exception support |
480 |
@section Exception support |
481 |
|
482 |
longjmp() is used when an exception such as division by zero is |
483 |
encountered. |
484 |
|
485 |
The host SIGSEGV and SIGBUS signal handlers are used to get invalid |
486 |
memory accesses. The simulated program counter is found by |
487 |
retranslating the corresponding basic block and by looking where the |
488 |
host program counter was at the exception point. |
489 |
|
490 |
The virtual CPU cannot retrieve the exact @code{EFLAGS} register because |
491 |
in some cases it is not computed because of condition code |
492 |
optimisations. It is not a big concern because the emulated code can |
493 |
still be restarted in any cases. |
494 |
|
495 |
@node MMU emulation |
496 |
@section MMU emulation |
497 |
|
498 |
For system emulation QEMU supports a soft MMU. In that mode, the MMU |
499 |
virtual to physical address translation is done at every memory |
500 |
access. QEMU uses an address translation cache to speed up the |
501 |
translation. |
502 |
|
503 |
In order to avoid flushing the translated code each time the MMU |
504 |
mappings change, QEMU uses a physically indexed translation cache. It |
505 |
means that each basic block is indexed with its physical address. |
506 |
|
507 |
When MMU mappings change, only the chaining of the basic blocks is |
508 |
reset (i.e. a basic block can no longer jump directly to another one). |
509 |
|
510 |
@node Device emulation |
511 |
@section Device emulation |
512 |
|
513 |
Systems emulated by QEMU are organized by boards. At initialization |
514 |
phase, each board instantiates a number of CPUs, devices, RAM and |
515 |
ROM. Each device in turn can assign I/O ports or memory areas (for |
516 |
MMIO) to its handlers. When the emulation starts, an access to the |
517 |
ports or MMIO memory areas assigned to the device causes the |
518 |
corresponding handler to be called. |
519 |
|
520 |
RAM and ROM are handled more optimally, only the offset to the host |
521 |
memory needs to be added to the guest address. |
522 |
|
523 |
The video RAM of VGA and other display cards is special: it can be |
524 |
read or written directly like RAM, but write accesses cause the memory |
525 |
to be marked with VGA_DIRTY flag as well. |
526 |
|
527 |
QEMU supports some device classes like serial and parallel ports, USB, |
528 |
drives and network devices, by providing APIs for easier connection to |
529 |
the generic, higher level implementations. The API hides the |
530 |
implementation details from the devices, like native device use or |
531 |
advanced block device formats like QCOW. |
532 |
|
533 |
Usually the devices implement a reset method and register support for |
534 |
saving and loading of the device state. The devices can also use |
535 |
timers, especially together with the use of bottom halves (BHs). |
536 |
|
537 |
@node Hardware interrupts |
538 |
@section Hardware interrupts |
539 |
|
540 |
In order to be faster, QEMU does not check at every basic block if an |
541 |
hardware interrupt is pending. Instead, the user must asynchronously |
542 |
call a specific function to tell that an interrupt is pending. This |
543 |
function resets the chaining of the currently executing basic |
544 |
block. It ensures that the execution will return soon in the main loop |
545 |
of the CPU emulator. Then the main loop can test if the interrupt is |
546 |
pending and handle it. |
547 |
|
548 |
@node User emulation specific details |
549 |
@section User emulation specific details |
550 |
|
551 |
@subsection Linux system call translation |
552 |
|
553 |
QEMU includes a generic system call translator for Linux. It means that |
554 |
the parameters of the system calls can be converted to fix the |
555 |
endianness and 32/64 bit issues. The IOCTLs are converted with a generic |
556 |
type description system (see @file{ioctls.h} and @file{thunk.c}). |
557 |
|
558 |
QEMU supports host CPUs which have pages bigger than 4KB. It records all |
559 |
the mappings the process does and try to emulated the @code{mmap()} |
560 |
system calls in cases where the host @code{mmap()} call would fail |
561 |
because of bad page alignment. |
562 |
|
563 |
@subsection Linux signals |
564 |
|
565 |
Normal and real-time signals are queued along with their information |
566 |
(@code{siginfo_t}) as it is done in the Linux kernel. Then an interrupt |
567 |
request is done to the virtual CPU. When it is interrupted, one queued |
568 |
signal is handled by generating a stack frame in the virtual CPU as the |
569 |
Linux kernel does. The @code{sigreturn()} system call is emulated to return |
570 |
from the virtual signal handler. |
571 |
|
572 |
Some signals (such as SIGALRM) directly come from the host. Other |
573 |
signals are synthesized from the virtual CPU exceptions such as SIGFPE |
574 |
when a division by zero is done (see @code{main.c:cpu_loop()}). |
575 |
|
576 |
The blocked signal mask is still handled by the host Linux kernel so |
577 |
that most signal system calls can be redirected directly to the host |
578 |
Linux kernel. Only the @code{sigaction()} and @code{sigreturn()} system |
579 |
calls need to be fully emulated (see @file{signal.c}). |
580 |
|
581 |
@subsection clone() system call and threads |
582 |
|
583 |
The Linux clone() system call is usually used to create a thread. QEMU |
584 |
uses the host clone() system call so that real host threads are created |
585 |
for each emulated thread. One virtual CPU instance is created for each |
586 |
thread. |
587 |
|
588 |
The virtual x86 CPU atomic operations are emulated with a global lock so |
589 |
that their semantic is preserved. |
590 |
|
591 |
Note that currently there are still some locking issues in QEMU. In |
592 |
particular, the translated cache flush is not protected yet against |
593 |
reentrancy. |
594 |
|
595 |
@subsection Self-virtualization |
596 |
|
597 |
QEMU was conceived so that ultimately it can emulate itself. Although |
598 |
it is not very useful, it is an important test to show the power of the |
599 |
emulator. |
600 |
|
601 |
Achieving self-virtualization is not easy because there may be address |
602 |
space conflicts. QEMU user emulators solve this problem by being an |
603 |
executable ELF shared object as the ld-linux.so ELF interpreter. That |
604 |
way, it can be relocated at load time. |
605 |
|
606 |
@node Bibliography |
607 |
@section Bibliography |
608 |
|
609 |
@table @asis |
610 |
|
611 |
@item [1] |
612 |
@url{http://citeseer.nj.nec.com/piumarta98optimizing.html}, Optimizing |
613 |
direct threaded code by selective inlining (1998) by Ian Piumarta, Fabio |
614 |
Riccardi. |
615 |
|
616 |
@item [2] |
617 |
@url{http://developer.kde.org/~sewardj/}, Valgrind, an open-source |
618 |
memory debugger for x86-GNU/Linux, by Julian Seward. |
619 |
|
620 |
@item [3] |
621 |
@url{http://bochs.sourceforge.net/}, the Bochs IA-32 Emulator Project, |
622 |
by Kevin Lawton et al. |
623 |
|
624 |
@item [4] |
625 |
@url{http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html}, the EM86 |
626 |
x86 emulator on Alpha-Linux. |
627 |
|
628 |
@item [5] |
629 |
@url{http://www.usenix.org/publications/library/proceedings/usenix-nt97/@/full_papers/chernoff/chernoff.pdf}, |
630 |
DIGITAL FX!32: Running 32-Bit x86 Applications on Alpha NT, by Anton |
631 |
Chernoff and Ray Hookway. |
632 |
|
633 |
@item [6] |
634 |
@url{http://www.willows.com/}, Windows API library emulation from |
635 |
Willows Software. |
636 |
|
637 |
@item [7] |
638 |
@url{http://user-mode-linux.sourceforge.net/}, |
639 |
The User-mode Linux Kernel. |
640 |
|
641 |
@item [8] |
642 |
@url{http://www.plex86.org/}, |
643 |
The new Plex86 project. |
644 |
|
645 |
@item [9] |
646 |
@url{http://www.vmware.com/}, |
647 |
The VMWare PC virtualizer. |
648 |
|
649 |
@item [10] |
650 |
@url{http://www.microsoft.com/windowsxp/virtualpc/}, |
651 |
The VirtualPC PC virtualizer. |
652 |
|
653 |
@item [11] |
654 |
@url{http://www.twoostwo.org/}, |
655 |
The TwoOStwo PC virtualizer. |
656 |
|
657 |
@item [12] |
658 |
@url{http://virtualbox.org/}, |
659 |
The VirtualBox PC virtualizer. |
660 |
|
661 |
@item [13] |
662 |
@url{http://www.xen.org/}, |
663 |
The Xen hypervisor. |
664 |
|
665 |
@item [14] |
666 |
@url{http://kvm.qumranet.com/kvmwiki/Front_Page}, |
667 |
Kernel Based Virtual Machine (KVM). |
668 |
|
669 |
@item [15] |
670 |
@url{http://www.greensocs.com/projects/QEMUSystemC}, |
671 |
QEMU-SystemC, a hardware co-simulator. |
672 |
|
673 |
@end table |
674 |
|
675 |
@node Regression Tests |
676 |
@chapter Regression Tests |
677 |
|
678 |
In the directory @file{tests/}, various interesting testing programs |
679 |
are available. They are used for regression testing. |
680 |
|
681 |
@menu |
682 |
* test-i386:: |
683 |
* linux-test:: |
684 |
@end menu |
685 |
|
686 |
@node test-i386 |
687 |
@section @file{test-i386} |
688 |
|
689 |
This program executes most of the 16 bit and 32 bit x86 instructions and |
690 |
generates a text output. It can be compared with the output obtained with |
691 |
a real CPU or another emulator. The target @code{make test} runs this |
692 |
program and a @code{diff} on the generated output. |
693 |
|
694 |
The Linux system call @code{modify_ldt()} is used to create x86 selectors |
695 |
to test some 16 bit addressing and 32 bit with segmentation cases. |
696 |
|
697 |
The Linux system call @code{vm86()} is used to test vm86 emulation. |
698 |
|
699 |
Various exceptions are raised to test most of the x86 user space |
700 |
exception reporting. |
701 |
|
702 |
@node linux-test |
703 |
@section @file{linux-test} |
704 |
|
705 |
This program tests various Linux system calls. It is used to verify |
706 |
that the system call parameters are correctly converted between target |
707 |
and host CPUs. |
708 |
|
709 |
@node Index |
710 |
@chapter Index |
711 |
@printindex cp |
712 |
|
713 |
@bye |