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

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

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

Hi,

Currently qemu-tech.texi is no longer in synch with QEMU development.
There are obsoleted references to code copying and dyngen versions,
TCG has changed a lot regarding code generation and target/host status
is no longer accurate.

In this patch I've tried to update the document based on my
understanding of how stuff works and what is the status of various
targets. Please comment.

[-- Attachment #2: update_qemu_tech.diff --]
[-- Type: plain/text, Size: 15174 bytes --]

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

[Edgar E. Iglesias]

On Sun, Oct 05, 2008 at 11:44:47AM +0300, Blue Swirl wrote:
> Hi,
> 
> Currently qemu-tech.texi is no longer in synch with QEMU development.
> There are obsoleted references to code copying and dyngen versions,
> TCG has changed a lot regarding code generation and target/host status
> is no longer accurate.
> 
> In this patch I've tried to update the document based on my
> understanding of how stuff works and what is the status of various
> targets. Please comment.

Hello Blue,

Great that somebody updates the docs!
I've got a comment:

 @node Condition code optimisations
 @section Condition code optimisations
@@ -343,15 +363,20 @@
 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.
+

At least CRIS does something similar, I guess it's not as nice as the one for x86 but it's there :)

Thanks

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

[Thiemo Seufer]

Edgar E. Iglesias wrote:
> On Sun, Oct 05, 2008 at 11:44:47AM +0300, Blue Swirl wrote:
> > Hi,
> > 
> > Currently qemu-tech.texi is no longer in synch with QEMU development.
> > There are obsoleted references to code copying and dyngen versions,
> > TCG has changed a lot regarding code generation and target/host status
> > is no longer accurate.
> > 
> > In this patch I've tried to update the document based on my
> > understanding of how stuff works and what is the status of various
> > targets. Please comment.
> 
> Hello Blue,
> 
> Great that somebody updates the docs!
> I've got a comment:
> 
>  @node Condition code optimisations
>  @section Condition code optimisations
> @@ -343,15 +363,20 @@
>  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.
> +
> 
> At least CRIS does something similar, I guess it's not as nice as the one for x86 but it's there :)

Also, it isn't implementable on MIPS, since MIPS has no condition
flags...


Thiemo

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

[malc]

On Sun, 5 Oct 2008, Blue Swirl wrote:

> Hi,
>
> Currently qemu-tech.texi is no longer in synch with QEMU development.
> There are obsoleted references to code copying and dyngen versions,
> TCG has changed a lot regarding code generation and target/host status
> is no longer accurate.
>
> In this patch I've tried to update the document based on my
> understanding of how stuff works and what is the status of various
> targets. Please comment.

I'm not sure what TCG "beging tested on" PowerPC32/64 really means
or when the testing will be completed. As far as i know TCG PPC stuff
is on par in every respect to that of x86[_64].

-- 
mailto:av1474@comtv.ru

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

[Paul Brook]

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

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

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

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.

[-- Attachment #2: update_qemu_tech.diff --]
[-- Type: plain/text, Size: 18848 bytes --]

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

[Paul Brook]

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

Looks ok to me.

Paul

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

[Laurent Desnogues]

A small typo:  qemu switched to tcg after the release of 0.9.1 and
not 0.9.0, didn't it?

I also find this wording not satisfying:

+TCG operations are then
+implemented in the host CPU back end, also known as TCG target

What about something like this:

TCG operations are then translated into host instructions by the CPU
back end, also known as TCG target

That's not the whole since we have helpers, but that looks closer to
the reality, at least for me :)


Laurent

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

[andrzej zaborowski]

I believe this piece is still valid:

-The most portable code uses an indirect jump. An indirect jump makes
-it easier to make the jump target modification atomic. On some host
-architectures (such as x86 or PowerPC), the @code{JUMP} opcode is
-directly patched so that the block chaining has no overhead.
-

BTW I wouldn't avoid the term TCG ops, it's sometimes clearer than operations.

Cheers

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

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Sun, Oct 05, 2008 at 11:44:47AM +0300, Blue Swirl wrote:
> Hi,
> 
> Currently qemu-tech.texi is no longer in synch with QEMU development.
> There are obsoleted references to code copying and dyngen versions,
> TCG has changed a lot regarding code generation and target/host status
> is no longer accurate.
> 
> In this patch I've tried to update the document based on my
> understanding of how stuff works and what is the status of various
> targets. Please comment.


@@ -124,9 +147,7 @@

 @itemize

-@item No SSE/MMX support (yet).
-
-@item No x86-64 support.
+@item Limited x86-64 support.

 @item IPC syscalls are missing.

I have posted update for IPC syscalls recently. Can anybody review it.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]