qemu-tech: move user mode emulation features from qemu-tech

These are interesting for users too, since nowadays most
qemu-user users are going to be somewhat technical rather than
just people that want to run Wine.  Some detail is lost, on
the other hand some of the information I removed (e.g. basic
block unchaining) was obsolete.

Reviewed-by: Emilio G. Cota <cota@braap.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

2 files changed, 34 insertions, 71 deletions

diff --git a/qemu-doc.texi b/qemu-doc.texi
index e60c46b5c9..227c2b0b45 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -2629,6 +2629,7 @@ so should only be used with trusted guest OS.
 
 @menu
 * Supported Operating Systems ::
+* Features::
 * Linux User space emulator::
 * BSD User space emulator ::
 @end menu
@@ -2645,6 +2646,39 @@ Linux (referred as qemu-linux-user)
 BSD (referred as qemu-bsd-user)
 @end itemize
 
+@node Features
+@section Features
+
+QEMU user space emulation has the following notable features:
+
+@table @strong
+@item System call translation:
+QEMU includes a generic system call translator.  This means that
+the parameters of the system calls can be converted to fix
+endianness and 32/64-bit mismatches between hosts and targets.
+IOCTLs can be converted too.
+
+@item POSIX signal handling:
+QEMU can redirect to the running program all signals coming from
+the host (such as @code{SIGALRM}), as well as synthesize signals from
+virtual CPU exceptions (for example @code{SIGFPE} when the program
+executes a division by zero).
+
+QEMU relies on the host kernel to emulate most signal system
+calls, for example to emulate the signal mask.  On Linux, QEMU
+supports both normal and real-time signals.
+
+@item Threading:
+On Linux, QEMU can emulate the @code{clone} syscall and create a real
+host thread (with a separate virtual CPU) for each emulated thread.
+Note that not all targets currently emulate atomic operations correctly.
+x86 and ARM use a global lock in order to preserve their semantics.
+@end table
+
+QEMU was conceived so that ultimately it can emulate itself. Although
+it is not very useful, it is an important test to show the power of the
+emulator.
+
 @node Linux User space emulator
 @section Linux User space emulator
 
diff --git a/qemu-tech.texi b/qemu-tech.texi
index 75ceea408c..16780a1503 100644
--- a/qemu-tech.texi
+++ b/qemu-tech.texi
@@ -221,8 +221,6 @@ SH4
 * Exception support::
 * MMU emulation::
 * Device emulation::
-* Hardware interrupts::
-* User emulation specific details::
 * Bibliography::
 @end menu
 
@@ -410,75 +408,6 @@ Usually the devices implement a reset method and register support for
 saving and loading of the device state. The devices can also use
 timers, especially together with the use of bottom halves (BHs).
 
-@node Hardware interrupts
-@section Hardware interrupts
-
-In order to be faster, QEMU does not check at every basic block if a
-hardware interrupt is pending. Instead, the user must asynchronously
-call a specific function to tell that an interrupt is pending. This
-function resets the chaining of the currently executing basic
-block. It ensures that the execution will return soon in the main loop
-of the CPU emulator. Then the main loop can test if the interrupt is
-pending and handle it.
-
-@node User emulation specific details
-@section User emulation specific details
-
-@subsection Linux system call translation
-
-QEMU includes a generic system call translator for Linux. It means that
-the parameters of the system calls can be converted to fix the
-endianness and 32/64 bit issues. The IOCTLs are converted with a generic
-type description system (see @file{ioctls.h} and @file{thunk.c}).
-
-QEMU supports host CPUs which have pages bigger than 4KB. It records all
-the mappings the process does and try to emulated the @code{mmap()}
-system calls in cases where the host @code{mmap()} call would fail
-because of bad page alignment.
-
-@subsection Linux signals
-
-Normal and real-time signals are queued along with their information
-(@code{siginfo_t}) as it is done in the Linux kernel. Then an interrupt
-request is done to the virtual CPU. When it is interrupted, one queued
-signal is handled by generating a stack frame in the virtual CPU as the
-Linux kernel does. The @code{sigreturn()} system call is emulated to return
-from the virtual signal handler.
-
-Some signals (such as SIGALRM) directly come from the host. Other
-signals are synthesized from the virtual CPU exceptions such as SIGFPE
-when a division by zero is done (see @code{main.c:cpu_loop()}).
-
-The blocked signal mask is still handled by the host Linux kernel so
-that most signal system calls can be redirected directly to the host
-Linux kernel. Only the @code{sigaction()} and @code{sigreturn()} system
-calls need to be fully emulated (see @file{signal.c}).
-
-@subsection clone() system call and threads
-
-The Linux clone() system call is usually used to create a thread. QEMU
-uses the host clone() system call so that real host threads are created
-for each emulated thread. One virtual CPU instance is created for each
-thread.
-
-The virtual x86 CPU atomic operations are emulated with a global lock so
-that their semantic is preserved.
-
-Note that currently there are still some locking issues in QEMU. In
-particular, the translated cache flush is not protected yet against
-reentrancy.
-
-@subsection Self-virtualization
-
-QEMU was conceived so that ultimately it can emulate itself. Although
-it is not very useful, it is an important test to show the power of the
-emulator.
-
-Achieving self-virtualization is not easy because there may be address
-space conflicts. QEMU user emulators solve this problem by being an
-executable ELF shared object as the ld-linux.so ELF interpreter. That
-way, it can be relocated at load time.
-
 @node Bibliography
 @section Bibliography