On 10/6/08, Paul Brook <paul@codesourcery.com> wrote:
> > -@item QEMU can either use a full software MMU for maximum portability or
>  > use the host system call mmap() to simulate the target MMU. +@item
>  > +QEMU can either use a full software MMU for maximum portability or use
>  > +an in-kernel accelerator (kqemu) to simulate the target MMU.
>
>  Referring to kqemu as a MMU simulator is at best very misleading. The item you
>  removed was referring to qemu-fast, which (in principle at least) still
>  worked for cross emulation.
>
>  kqemu and kvm execute [some of] the guest code natively, while continuing to
>  emulate the rest of the machine.
>
>  > Various
>  > +hardware devices can be emulated and in some cases, host devices
>  > +(e.g. serial and parallel ports, USB, drives) can be used
>  > +transparently by the guest Operating System for maximum performance.
>
>  This should be a seaprate item. As written it's unclear whether this is a
>  kqemu feature or available all the time.
>
>  Host device passthrough is generally used for talking to external physical
>  peripherals (e.g. a webcam, modem or tape drive), and not for performance
>  reasons.
>
>
>  >  the condition codes are not needed by the next instructions, no
>  >  condition codes are computed at all.
>  >
>  > +This optimization is not yet implemented on other targets.
>
>
> I don't think this back propagation pass exists at all now. It was made
>  redundant by the TCG liveness pass.
>
>  The lazy condition code evaluation is used on x86, m68k and cris. ARM uses a
>  simplified variant for the N and Z flags.
>
>  You might consider rewording the initial paragraph to say that lazy flag
>  evaluation is important for CPUs where every instruction sets the condition
>  codes.  It tends to be less important on conventional RISC systems where
>  condition codes are only updated when explicitly requested.

Okay, I updated the patch based on these comments.

I also added some words about SMP and condition codes and a new
chapter for device emulation.