vcs.maemo.org Git - qemu/blob - qemu/qemu-tech.html

   1 <HTML>
   2 <HEAD>
   3 <!-- Created by texi2html 1.56k from qemu-tech.texi on 19 December 2005 -->
   4
   5 <TITLE>QEMU Internals</TITLE>
   6 </HEAD>
   7 <BODY>
   8 <H1>QEMU Internals</H1>
   9 <P>
  10 <P><HR><P>
  11 <H1>Table of Contents</H1>
  12 <UL>
  13 <LI><A NAME="TOC1" HREF="qemu-tech.html#SEC1">1. Introduction</A>
  14 <UL>
  15 <LI><A NAME="TOC2" HREF="qemu-tech.html#SEC2">1.1 Features</A>
  16 <LI><A NAME="TOC3" HREF="qemu-tech.html#SEC3">1.2 x86 emulation</A>
  17 <LI><A NAME="TOC4" HREF="qemu-tech.html#SEC4">1.3 ARM emulation</A>
  18 <LI><A NAME="TOC5" HREF="qemu-tech.html#SEC5">1.4 PowerPC emulation</A>
  19 <LI><A NAME="TOC6" HREF="qemu-tech.html#SEC6">1.5 SPARC emulation</A>
  20 </UL>
  21 <LI><A NAME="TOC7" HREF="qemu-tech.html#SEC7">2. QEMU Internals</A>
  22 <UL>
  23 <LI><A NAME="TOC8" HREF="qemu-tech.html#SEC8">2.1 QEMU compared to other emulators</A>
  24 <LI><A NAME="TOC9" HREF="qemu-tech.html#SEC9">2.2 Portable dynamic translation</A>
  25 <LI><A NAME="TOC10" HREF="qemu-tech.html#SEC10">2.3 Register allocation</A>
  26 <LI><A NAME="TOC11" HREF="qemu-tech.html#SEC11">2.4 Condition code optimisations</A>
  27 <LI><A NAME="TOC12" HREF="qemu-tech.html#SEC12">2.5 CPU state optimisations</A>
  28 <LI><A NAME="TOC13" HREF="qemu-tech.html#SEC13">2.6 Translation cache</A>
  29 <LI><A NAME="TOC14" HREF="qemu-tech.html#SEC14">2.7 Direct block chaining</A>
  30 <LI><A NAME="TOC15" HREF="qemu-tech.html#SEC15">2.8 Self-modifying code and translated code invalidation</A>
  31 <LI><A NAME="TOC16" HREF="qemu-tech.html#SEC16">2.9 Exception support</A>
  32 <LI><A NAME="TOC17" HREF="qemu-tech.html#SEC17">2.10 MMU emulation</A>
  33 <LI><A NAME="TOC18" HREF="qemu-tech.html#SEC18">2.11 Hardware interrupts</A>
  34 <LI><A NAME="TOC19" HREF="qemu-tech.html#SEC19">2.12 User emulation specific details</A>
  35 <UL>
  36 <LI><A NAME="TOC20" HREF="qemu-tech.html#SEC20">2.12.1 Linux system call translation</A>
  37 <LI><A NAME="TOC21" HREF="qemu-tech.html#SEC21">2.12.2 Linux signals</A>
  38 <LI><A NAME="TOC22" HREF="qemu-tech.html#SEC22">2.12.3 clone() system call and threads</A>
  39 <LI><A NAME="TOC23" HREF="qemu-tech.html#SEC23">2.12.4 Self-virtualization</A>
  40 </UL>
  41 <LI><A NAME="TOC24" HREF="qemu-tech.html#SEC24">2.13 Bibliography</A>
  42 </UL>
  43 <LI><A NAME="TOC25" HREF="qemu-tech.html#SEC25">3. Regression Tests</A>
  44 <UL>
  45 <LI><A NAME="TOC26" HREF="qemu-tech.html#SEC26">3.1 <TT>`test-i386'</TT></A>
  46 <LI><A NAME="TOC27" HREF="qemu-tech.html#SEC27">3.2 <TT>`linux-test'</TT></A>
  47 <LI><A NAME="TOC28" HREF="qemu-tech.html#SEC28">3.3 <TT>`qruncom.c'</TT></A>
  48 </UL>
  49 </UL>
  50 <P><HR><P>
  51
  52 <P>
  53 QEMU Internals
  54
  55
  56
  57
  58 <H1><A NAME="SEC1" HREF="qemu-tech.html#TOC1">1. Introduction</A></H1>
  59
  60
  61
  62 <H2><A NAME="SEC2" HREF="qemu-tech.html#TOC2">1.1 Features</A></H2>
  63
  64 <P>
  65 QEMU is a FAST! processor emulator using a portable dynamic
  66 translator.
  67
  68
  69 <P>
  70 QEMU has two operating modes:
  71
  72
  73
  74 <UL>
  75
  76 <LI>
  77
  78 Full system emulation. In this mode, QEMU emulates a full system
  79 (usually a PC), including a processor and various peripherals. It can
  80 be used to launch an different Operating System without rebooting the
  81 PC or to debug system code.
  82
  83 <LI>
  84
  85 User mode emulation (Linux host only). In this mode, QEMU can launch
  86 Linux processes compiled for one CPU on another CPU. It can be used to
  87 launch the Wine Windows API emulator (<A HREF="http://www.winehq.org">http://www.winehq.org</A>) or
  88 to ease cross-compilation and cross-debugging.
  89
  90 </UL>
  91
  92 <P>
  93 As QEMU requires no host kernel driver to run, it is very safe and
  94 easy to use.
  95
  96
  97 <P>
  98 QEMU generic features:
  99
 100
 101
 102 <UL>
 103
 104 <LI>User space only or full system emulation.
 105
 106 <LI>Using dynamic translation to native code for reasonnable speed.
 107
 108 <LI>Working on x86 and PowerPC hosts. Being tested on ARM, Sparc32, Alpha and S390.
 109
 110 <LI>Self-modifying code support.
 111
 112 <LI>Precise exceptions support.
 113
 114 <LI>The virtual CPU is a library (<CODE>libqemu</CODE>) which can be used
 115
 116 in other projects (look at <TT>`qemu/tests/qruncom.c'</TT> to have an
 117 example of user mode <CODE>libqemu</CODE> usage).
 118
 119 </UL>
 120
 121 <P>
 122 QEMU user mode emulation features:
 123
 124 <UL>
 125 <LI>Generic Linux system call converter, including most ioctls.
 126
 127 <LI>clone() emulation using native CPU clone() to use Linux scheduler for threads.
 128
 129 <LI>Accurate signal handling by remapping host signals to target signals.
 130
 131 </UL>
 132
 133 </UL>
 134
 135 QEMU full system emulation features:
 136
 137 <UL>
 138 <LI>QEMU can either use a full software MMU for maximum portability or use the host system call mmap() to simulate the target MMU.
 139
 140 </UL>
 141
 142
 143
 144 <H2><A NAME="SEC3" HREF="qemu-tech.html#TOC3">1.2 x86 emulation</A></H2>
 145
 146 <P>
 147 QEMU x86 target features:
 148
 149
 150
 151 <UL>
 152
 153 <LI>The virtual x86 CPU supports 16 bit and 32 bit addressing with segmentation.
 154
 155 LDT/GDT and IDT are emulated. VM86 mode is also supported to run DOSEMU.
 156
 157 <LI>Support of host page sizes bigger than 4KB in user mode emulation.
 158
 159 <LI>QEMU can emulate itself on x86.
 160
 161 <LI>An extensive Linux x86 CPU test program is included <TT>`tests/test-i386'</TT>.
 162
 163 It can be used to test other x86 virtual CPUs.
 164
 165 </UL>
 166
 167 <P>
 168 Current QEMU limitations:
 169
 170
 171
 172 <UL>
 173
 174 <LI>No SSE/MMX support (yet).
 175
 176 <LI>No x86-64 support.
 177
 178 <LI>IPC syscalls are missing.
 179
 180 <LI>The x86 segment limits and access rights are not tested at every
 181
 182 memory access (yet). Hopefully, very few OSes seem to rely on that for
 183 normal use.
 184
 185 <LI>On non x86 host CPUs, <CODE>double</CODE>s are used instead of the non standard
 186
 187 10 byte <CODE>long double</CODE>s of x86 for floating point emulation to get
 188 maximum performances.
 189
 190 </UL>
 191
 192
 193
 194 <H2><A NAME="SEC4" HREF="qemu-tech.html#TOC4">1.3 ARM emulation</A></H2>
 195
 196
 197 <UL>
 198
 199 <LI>Full ARM 7 user emulation.
 200
 201 <LI>NWFPE FPU support included in user Linux emulation.
 202
 203 <LI>Can run most ARM Linux binaries.
 204
 205 </UL>
 206
 207
 208
 209 <H2><A NAME="SEC5" HREF="qemu-tech.html#TOC5">1.4 PowerPC emulation</A></H2>
 210
 211
 212 <UL>
 213
 214 <LI>Full PowerPC 32 bit emulation, including privileged instructions,
 215
 216 FPU and MMU.
 217
 218 <LI>Can run most PowerPC Linux binaries.
 219
 220 </UL>
 221
 222
 223
 224 <H2><A NAME="SEC6" HREF="qemu-tech.html#TOC6">1.5 SPARC emulation</A></H2>
 225
 226
 227 <UL>
 228
 229 <LI>Somewhat complete SPARC V8 emulation, including privileged
 230
 231 instructions, FPU and MMU. SPARC V9 emulation includes most privileged
 232 instructions, FPU and I/D MMU, but misses VIS instructions.
 233
 234 <LI>Can run some 32-bit SPARC Linux binaries.
 235
 236 </UL>
 237
 238 <P>
 239 Current QEMU limitations:
 240
 241
 242
 243 <UL>
 244
 245 <LI>Tagged add/subtract instructions are not supported, but they are
 246
 247 probably not used.
 248
 249 <LI>IPC syscalls are missing.
 250
 251 <LI>128-bit floating point operations are not supported, though none of the
 252
 253 real CPUs implement them either. FCMPE[SD] are not correctly
 254 implemented.  Floating point exception support is untested.
 255
 256 <LI>Alignment is not enforced at all.
 257
 258 <LI>Atomic instructions are not correctly implemented.
 259
 260 <LI>Sparc64 emulators are not usable for anything yet.
 261
 262 </UL>
 263
 264
 265
 266 <H1><A NAME="SEC7" HREF="qemu-tech.html#TOC7">2. QEMU Internals</A></H1>
 267
 268
 269
 270 <H2><A NAME="SEC8" HREF="qemu-tech.html#TOC8">2.1 QEMU compared to other emulators</A></H2>
 271
 272 <P>
 273 Like bochs <A HREF="qemu-tech.html#BIB3">[3]</A>, QEMU emulates an x86 CPU. But QEMU is much faster than
 274 bochs as it uses dynamic compilation. Bochs is closely tied to x86 PC
 275 emulation while QEMU can emulate several processors.
 276
 277
 278 <P>
 279 Like Valgrind <A HREF="qemu-tech.html#BIB2">[2]</A>, QEMU does user space emulation and dynamic
 280 translation. Valgrind is mainly a memory debugger while QEMU has no
 281 support for it (QEMU could be used to detect out of bound memory
 282 accesses as Valgrind, but it has no support to track uninitialised data
 283 as Valgrind does). The Valgrind dynamic translator generates better code
 284 than QEMU (in particular it does register allocation) but it is closely
 285 tied to an x86 host and target and has no support for precise exceptions
 286 and system emulation.
 287
 288
 289 <P>
 290 EM86 <A HREF="qemu-tech.html#BIB4">[4]</A> is the closest project to user space QEMU (and QEMU still uses
 291 some of its code, in particular the ELF file loader). EM86 was limited
 292 to an alpha host and used a proprietary and slow interpreter (the
 293 interpreter part of the FX!32 Digital Win32 code translator <A HREF="qemu-tech.html#BIB5">[5]</A>).
 294
 295
 296 <P>
 297 TWIN <A HREF="qemu-tech.html#BIB6">[6]</A> is a Windows API emulator like Wine. It is less accurate than
 298 Wine but includes a protected mode x86 interpreter to launch x86 Windows
 299 executables. Such an approach has greater potential because most of the
 300 Windows API is executed natively but it is far more difficult to develop
 301 because all the data structures and function parameters exchanged
 302 between the API and the x86 code must be converted.
 303
 304
 305 <P>
 306 User mode Linux <A HREF="qemu-tech.html#BIB7">[7]</A> was the only solution before QEMU to launch a
 307 Linux kernel as a process while not needing any host kernel
 308 patches. However, user mode Linux requires heavy kernel patches while
 309 QEMU accepts unpatched Linux kernels. The price to pay is that QEMU is
 310 slower.
 311
 312
 313 <P>
 314 The new Plex86 <A HREF="qemu-tech.html#BIB8">[8]</A> PC virtualizer is done in the same spirit as the
 315 qemu-fast system emulator. It requires a patched Linux kernel to work
 316 (you cannot launch the same kernel on your PC), but the patches are
 317 really small. As it is a PC virtualizer (no emulation is done except
 318 for some priveledged instructions), it has the potential of being
 319 faster than QEMU. The downside is that a complicated (and potentially
 320 unsafe) host kernel patch is needed.
 321
 322
 323 <P>
 324 The commercial PC Virtualizers (VMWare <A HREF="qemu-tech.html#BIB9">[9]</A>, VirtualPC <A HREF="qemu-tech.html#BIB10">[10]</A>, TwoOStwo
 325 <A HREF="qemu-tech.html#BIB11">[11]</A>) are faster than QEMU, but they all need specific, proprietary
 326 and potentially unsafe host drivers. Moreover, they are unable to
 327 provide cycle exact simulation as an emulator can.
 328
 329
 330
 331
 332 <H2><A NAME="SEC9" HREF="qemu-tech.html#TOC9">2.2 Portable dynamic translation</A></H2>
 333
 334 <P>
 335 QEMU is a dynamic translator. When it first encounters a piece of code,
 336 it converts it to the host instruction set. Usually dynamic translators
 337 are very complicated and highly CPU dependent. QEMU uses some tricks
 338 which make it relatively easily portable and simple while achieving good
 339 performances.
 340
 341
 342 <P>
 343 The basic idea is to split every x86 instruction into fewer simpler
 344 instructions. Each simple instruction is implemented by a piece of C
 345 code (see <TT>`target-i386/op.c'</TT>). Then a compile time tool
 346 (<TT>`dyngen'</TT>) takes the corresponding object file (<TT>`op.o'</TT>)
 347 to generate a dynamic code generator which concatenates the simple
 348 instructions to build a function (see <TT>`op.h:dyngen_code()'</TT>).
 349
 350
 351 <P>
 352 In essence, the process is similar to <A HREF="qemu-tech.html#BIB1">[1]</A>, but more work is done at
 353 compile time.
 354
 355
 356 <P>
 357 A key idea to get optimal performances is that constant parameters can
 358 be passed to the simple operations. For that purpose, dummy ELF
 359 relocations are generated with gcc for each constant parameter. Then,
 360 the tool (<TT>`dyngen'</TT>) can locate the relocations and generate the
 361 appriopriate C code to resolve them when building the dynamic code.
 362
 363
 364 <P>
 365 That way, QEMU is no more difficult to port than a dynamic linker.
 366
 367
 368 <P>
 369 To go even faster, GCC static register variables are used to keep the
 370 state of the virtual CPU.
 371
 372
 373
 374
 375 <H2><A NAME="SEC10" HREF="qemu-tech.html#TOC10">2.3 Register allocation</A></H2>
 376
 377 <P>
 378 Since QEMU uses fixed simple instructions, no efficient register
 379 allocation can be done. However, because RISC CPUs have a lot of
 380 register, most of the virtual CPU state can be put in registers without
 381 doing complicated register allocation.
 382
 383
 384
 385
 386 <H2><A NAME="SEC11" HREF="qemu-tech.html#TOC11">2.4 Condition code optimisations</A></H2>
 387
 388 <P>
 389 Good CPU condition codes emulation (<CODE>EFLAGS</CODE> register on x86) is a
 390 critical point to get good performances. QEMU uses lazy condition code
 391 evaluation: instead of computing the condition codes after each x86
 392 instruction, it just stores one operand (called <CODE>CC_SRC</CODE>), the
 393 result (called <CODE>CC_DST</CODE>) and the type of operation (called
 394 <CODE>CC_OP</CODE>).
 395
 396
 397 <P>
 398 <CODE>CC_OP</CODE> is almost never explicitely set in the generated code
 399 because it is known at translation time.
 400
 401
 402 <P>
 403 In order to increase performances, a backward pass is performed on the
 404 generated simple instructions (see
 405 <CODE>target-i386/translate.c:optimize_flags()</CODE>). When it can be proved that
 406 the condition codes are not needed by the next instructions, no
 407 condition codes are computed at all.
 408
 409
 410
 411
 412 <H2><A NAME="SEC12" HREF="qemu-tech.html#TOC12">2.5 CPU state optimisations</A></H2>
 413
 414 <P>
 415 The x86 CPU has many internal states which change the way it evaluates
 416 instructions. In order to achieve a good speed, the translation phase
 417 considers that some state information of the virtual x86 CPU cannot
 418 change in it. For example, if the SS, DS and ES segments have a zero
 419 base, then the translator does not even generate an addition for the
 420 segment base.
 421
 422
 423 <P>
 424 [The FPU stack pointer register is not handled that way yet].
 425
 426
 427
 428
 429 <H2><A NAME="SEC13" HREF="qemu-tech.html#TOC13">2.6 Translation cache</A></H2>
 430
 431 <P>
 432 A 16 MByte cache holds the most recently used translations. For
 433 simplicity, it is completely flushed when it is full. A translation unit
 434 contains just a single basic block (a block of x86 instructions
 435 terminated by a jump or by a virtual CPU state change which the
 436 translator cannot deduce statically).
 437
 438
 439
 440
 441 <H2><A NAME="SEC14" HREF="qemu-tech.html#TOC14">2.7 Direct block chaining</A></H2>
 442
 443 <P>
 444 After each translated basic block is executed, QEMU uses the simulated
 445 Program Counter (PC) and other cpu state informations (such as the CS
 446 segment base value) to find the next basic block.
 447
 448
 449 <P>
 450 In order to accelerate the most common cases where the new simulated PC
 451 is known, QEMU can patch a basic block so that it jumps directly to the
 452 next one.
 453
 454
 455 <P>
 456 The most portable code uses an indirect jump. An indirect jump makes
 457 it easier to make the jump target modification atomic. On some host
 458 architectures (such as x86 or PowerPC), the <CODE>JUMP</CODE> opcode is
 459 directly patched so that the block chaining has no overhead.
 460
 461
 462
 463
 464 <H2><A NAME="SEC15" HREF="qemu-tech.html#TOC15">2.8 Self-modifying code and translated code invalidation</A></H2>
 465
 466 <P>
 467 Self-modifying code is a special challenge in x86 emulation because no
 468 instruction cache invalidation is signaled by the application when code
 469 is modified.
 470
 471
 472 <P>
 473 When translated code is generated for a basic block, the corresponding
 474 host page is write protected if it is not already read-only (with the
 475 system call <CODE>mprotect()</CODE>). Then, if a write access is done to the
 476 page, Linux raises a SEGV signal. QEMU then invalidates all the
 477 translated code in the page and enables write accesses to the page.
 478
 479
 480 <P>
 481 Correct translated code invalidation is done efficiently by maintaining
 482 a linked list of every translated block contained in a given page. Other
 483 linked lists are also maintained to undo direct block chaining.
 484
 485
 486 <P>
 487 Although the overhead of doing <CODE>mprotect()</CODE> calls is important,
 488 most MSDOS programs can be emulated at reasonnable speed with QEMU and
 489 DOSEMU.
 490
 491
 492 <P>
 493 Note that QEMU also invalidates pages of translated code when it detects
 494 that memory mappings are modified with <CODE>mmap()</CODE> or <CODE>munmap()</CODE>.
 495
 496
 497 <P>
 498 When using a software MMU, the code invalidation is more efficient: if
 499 a given code page is invalidated too often because of write accesses,
 500 then a bitmap representing all the code inside the page is
 501 built. Every store into that page checks the bitmap to see if the code
 502 really needs to be invalidated. It avoids invalidating the code when
 503 only data is modified in the page.
 504
 505
 506
 507
 508 <H2><A NAME="SEC16" HREF="qemu-tech.html#TOC16">2.9 Exception support</A></H2>
 509
 510 <P>
 511 longjmp() is used when an exception such as division by zero is
 512 encountered.
 513
 514
 515 <P>
 516 The host SIGSEGV and SIGBUS signal handlers are used to get invalid
 517 memory accesses. The exact CPU state can be retrieved because all the
 518 x86 registers are stored in fixed host registers. The simulated program
 519 counter is found by retranslating the corresponding basic block and by
 520 looking where the host program counter was at the exception point.
 521
 522
 523 <P>
 524 The virtual CPU cannot retrieve the exact <CODE>EFLAGS</CODE> register because
 525 in some cases it is not computed because of condition code
 526 optimisations. It is not a big concern because the emulated code can
 527 still be restarted in any cases.
 528
 529
 530
 531
 532 <H2><A NAME="SEC17" HREF="qemu-tech.html#TOC17">2.10 MMU emulation</A></H2>
 533
 534 <P>
 535 For system emulation, QEMU uses the mmap() system call to emulate the
 536 target CPU MMU. It works as long the emulated OS does not use an area
 537 reserved by the host OS (such as the area above 0xc0000000 on x86
 538 Linux).
 539
 540
 541 <P>
 542 In order to be able to launch any OS, QEMU also supports a soft
 543 MMU. In that mode, the MMU virtual to physical address translation is
 544 done at every memory access. QEMU uses an address translation cache to
 545 speed up the translation.
 546
 547
 548 <P>
 549 In order to avoid flushing the translated code each time the MMU
 550 mappings change, QEMU uses a physically indexed translation cache. It
 551 means that each basic block is indexed with its physical address.
 552
 553
 554 <P>
 555 When MMU mappings change, only the chaining of the basic blocks is
 556 reset (i.e. a basic block can no longer jump directly to another one).
 557
 558
 559
 560
 561 <H2><A NAME="SEC18" HREF="qemu-tech.html#TOC18">2.11 Hardware interrupts</A></H2>
 562
 563 <P>
 564 In order to be faster, QEMU does not check at every basic block if an
 565 hardware interrupt is pending. Instead, the user must asynchrously
 566 call a specific function to tell that an interrupt is pending. This
 567 function resets the chaining of the currently executing basic
 568 block. It ensures that the execution will return soon in the main loop
 569 of the CPU emulator. Then the main loop can test if the interrupt is
 570 pending and handle it.
 571
 572
 573
 574
 575 <H2><A NAME="SEC19" HREF="qemu-tech.html#TOC19">2.12 User emulation specific details</A></H2>
 576
 577
 578
 579 <H3><A NAME="SEC20" HREF="qemu-tech.html#TOC20">2.12.1 Linux system call translation</A></H3>
 580
 581 <P>
 582 QEMU includes a generic system call translator for Linux. It means that
 583 the parameters of the system calls can be converted to fix the
 584 endianness and 32/64 bit issues. The IOCTLs are converted with a generic
 585 type description system (see <TT>`ioctls.h'</TT> and <TT>`thunk.c'</TT>).
 586
 587
 588 <P>
 589 QEMU supports host CPUs which have pages bigger than 4KB. It records all
 590 the mappings the process does and try to emulated the <CODE>mmap()</CODE>
 591 system calls in cases where the host <CODE>mmap()</CODE> call would fail
 592 because of bad page alignment.
 593
 594
 595
 596
 597 <H3><A NAME="SEC21" HREF="qemu-tech.html#TOC21">2.12.2 Linux signals</A></H3>
 598
 599 <P>
 600 Normal and real-time signals are queued along with their information
 601 (<CODE>siginfo_t</CODE>) as it is done in the Linux kernel. Then an interrupt
 602 request is done to the virtual CPU. When it is interrupted, one queued
 603 signal is handled by generating a stack frame in the virtual CPU as the
 604 Linux kernel does. The <CODE>sigreturn()</CODE> system call is emulated to return
 605 from the virtual signal handler.
 606
 607
 608 <P>
 609 Some signals (such as SIGALRM) directly come from the host. Other
 610 signals are synthetized from the virtual CPU exceptions such as SIGFPE
 611 when a division by zero is done (see <CODE>main.c:cpu_loop()</CODE>).
 612
 613
 614 <P>
 615 The blocked signal mask is still handled by the host Linux kernel so
 616 that most signal system calls can be redirected directly to the host
 617 Linux kernel. Only the <CODE>sigaction()</CODE> and <CODE>sigreturn()</CODE> system
 618 calls need to be fully emulated (see <TT>`signal.c'</TT>).
 619
 620
 621
 622
 623 <H3><A NAME="SEC22" HREF="qemu-tech.html#TOC22">2.12.3 clone() system call and threads</A></H3>
 624
 625 <P>
 626 The Linux clone() system call is usually used to create a thread. QEMU
 627 uses the host clone() system call so that real host threads are created
 628 for each emulated thread. One virtual CPU instance is created for each
 629 thread.
 630
 631
 632 <P>
 633 The virtual x86 CPU atomic operations are emulated with a global lock so
 634 that their semantic is preserved.
 635
 636
 637 <P>
 638 Note that currently there are still some locking issues in QEMU. In
 639 particular, the translated cache flush is not protected yet against
 640 reentrancy.
 641
 642
 643
 644
 645 <H3><A NAME="SEC23" HREF="qemu-tech.html#TOC23">2.12.4 Self-virtualization</A></H3>
 646
 647 <P>
 648 QEMU was conceived so that ultimately it can emulate itself. Although
 649 it is not very useful, it is an important test to show the power of the
 650 emulator.
 651
 652
 653 <P>
 654 Achieving self-virtualization is not easy because there may be address
 655 space conflicts. QEMU solves this problem by being an executable ELF
 656 shared object as the ld-linux.so ELF interpreter. That way, it can be
 657 relocated at load time.
 658
 659
 660
 661
 662 <H2><A NAME="SEC24" HREF="qemu-tech.html#TOC24">2.13 Bibliography</A></H2>
 663
 664 <DL COMPACT>
 665
 666 <DT><A NAME="BIB1">[1]</A>
 667 <DD>
 668 <A HREF="http://citeseer.nj.nec.com/piumarta98optimizing.html">http://citeseer.nj.nec.com/piumarta98optimizing.html</A>, Optimizing
 669 direct threaded code by selective inlining (1998) by Ian Piumarta, Fabio
 670 Riccardi.
 671
 672 <DT><A NAME="BIB2">[2]</A>
 673 <DD>
 674 <A HREF="http://developer.kde.org/~sewardj/">http://developer.kde.org/~sewardj/</A>, Valgrind, an open-source
 675 memory debugger for x86-GNU/Linux, by Julian Seward.
 676
 677 <DT><A NAME="BIB3">[3]</A>
 678 <DD>
 679 <A HREF="http://bochs.sourceforge.net/">http://bochs.sourceforge.net/</A>, the Bochs IA-32 Emulator Project,
 680 by Kevin Lawton et al.
 681
 682 <DT><A NAME="BIB4">[4]</A>
 683 <DD>
 684 <A HREF="http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html">http://www.cs.rose-hulman.edu/~donaldlf/em86/index.html</A>, the EM86
 685 x86 emulator on Alpha-Linux.
 686
 687 <DT><A NAME="BIB5">[5]</A>
 688 <DD>
 689 <A HREF="http://www.usenix.org/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf">http://www.usenix.org/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf</A>,
 690 DIGITAL FX!32: Running 32-Bit x86 Applications on Alpha NT, by Anton
 691 Chernoff and Ray Hookway.
 692
 693 <DT><A NAME="BIB6">[6]</A>
 694 <DD>
 695 <A HREF="http://www.willows.com/">http://www.willows.com/</A>, Windows API library emulation from
 696 Willows Software.
 697
 698 <DT><A NAME="BIB7">[7]</A>
 699 <DD>
 700 <A HREF="http://user-mode-linux.sourceforge.net/">http://user-mode-linux.sourceforge.net/</A>,
 701 The User-mode Linux Kernel.
 702
 703 <DT><A NAME="BIB8">[8]</A>
 704 <DD>
 705 <A HREF="http://www.plex86.org/">http://www.plex86.org/</A>,
 706 The new Plex86 project.
 707
 708 <DT><A NAME="BIB9">[9]</A>
 709 <DD>
 710 <A HREF="http://www.vmware.com/">http://www.vmware.com/</A>,
 711 The VMWare PC virtualizer.
 712
 713 <DT><A NAME="BIB10">[10]</A>
 714 <DD>
 715 <A HREF="http://www.microsoft.com/windowsxp/virtualpc/">http://www.microsoft.com/windowsxp/virtualpc/</A>,
 716 The VirtualPC PC virtualizer.
 717
 718 <DT><A NAME="BIB11">[11]</A>
 719 <DD>
 720 <A HREF="http://www.twoostwo.org/">http://www.twoostwo.org/</A>,
 721 The TwoOStwo PC virtualizer.
 722
 723 </DL>
 724
 725
 726
 727 <H1><A NAME="SEC25" HREF="qemu-tech.html#TOC25">3. Regression Tests</A></H1>
 728
 729 <P>
 730 In the directory <TT>`tests/'</TT>, various interesting testing programs
 731 are available. There are used for regression testing.
 732
 733
 734
 735
 736 <H2><A NAME="SEC26" HREF="qemu-tech.html#TOC26">3.1 <TT>`test-i386'</TT></A></H2>
 737
 738 <P>
 739 This program executes most of the 16 bit and 32 bit x86 instructions and
 740 generates a text output. It can be compared with the output obtained with
 741 a real CPU or another emulator. The target <CODE>make test</CODE> runs this
 742 program and a <CODE>diff</CODE> on the generated output.
 743
 744
 745 <P>
 746 The Linux system call <CODE>modify_ldt()</CODE> is used to create x86 selectors
 747 to test some 16 bit addressing and 32 bit with segmentation cases.
 748
 749
 750 <P>
 751 The Linux system call <CODE>vm86()</CODE> is used to test vm86 emulation.
 752
 753
 754 <P>
 755 Various exceptions are raised to test most of the x86 user space
 756 exception reporting.
 757
 758
 759
 760
 761 <H2><A NAME="SEC27" HREF="qemu-tech.html#TOC27">3.2 <TT>`linux-test'</TT></A></H2>
 762
 763 <P>
 764 This program tests various Linux system calls. It is used to verify
 765 that the system call parameters are correctly converted between target
 766 and host CPUs.
 767
 768
 769
 770
 771 <H2><A NAME="SEC28" HREF="qemu-tech.html#TOC28">3.3 <TT>`qruncom.c'</TT></A></H2>
 772
 773 <P>
 774 Example of usage of <CODE>libqemu</CODE> to emulate a user mode i386 CPU.
 775 <P><HR><P>
 776 This document was generated on 19 December 2005 using
 777 <A HREF="http://wwwinfo.cern.ch/dis/texi2html/">texi2html</A>&nbsp;1.56k.
 778 </BODY>
 779 </HTML>