qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH, RFC] Update qemu-tech.texi, needs verification


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH, RFC] Update qemu-tech.texi, needs verification
Date: Mon, 6 Oct 2008 20:53:12 +0300

On 10/6/08, Paul Brook <address@hidden> wrote:
> > address@hidden QEMU can either use a full software MMU for maximum 
> > portability or
>  > use the host system call mmap() to simulate the target MMU. address@hidden
>  > +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.

Attachment: update_qemu_tech.diff
Description: plain/text


reply via email to

[Prev in Thread] Current Thread [Next in Thread]