qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Blue Swirl <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] [PATCH, RFC] Update qemu-tech.texi, needs verification
Date: Mon, 6 Oct 2008 14:26:54 +0100	[thread overview]
Message-ID: <200810061426.54453.paul@codesourcery.com> (raw)
In-Reply-To: <f43fc5580810050144t7f1d6d15ie006558f63f10953@mail.gmail.com>

> -@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.


Paul

  parent reply	other threads:[~2008-10-06 13:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-05  8:44 [Qemu-devel] [PATCH, RFC] Update qemu-tech.texi, needs verification Blue Swirl
2008-10-05 12:26 ` Edgar E. Iglesias
2008-10-05 12:55   ` Thiemo Seufer
2008-10-05 17:28 ` malc
2008-10-06 13:26 ` Paul Brook [this message]
2008-10-06 17:53   ` Blue Swirl
2008-10-06 18:02     ` Paul Brook
2008-10-06 18:19     ` Laurent Desnogues
2008-10-06 19:09       ` andrzej zaborowski
2008-10-10  6:56 ` Kirill A. Shutemov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200810061426.54453.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=blauwirbel@gmail.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).