Re: [Qemu-devel] Code Copy / New Linux boot code

["Jamie Burns" <jamie.burns@dynamicexpression.co.uk>]

Wow. Thanks for your hard work!

The x86 to x86 is just what I was hoping for - a fast case where host/target
CPU are the same architecture.

When I get some time, I plan to write some software for WindowsXP, so that
it will be able to export application windows in such a way that they can be
seen as "rootless" windows in a seperate windowing environment (on X11
etc.).

What this would mean for a virtual machine like Qemu is that Windows
applications could be run on Linux at near native speeds. Think of it like
Mac OSX's Classic environment - in this case, you load up Windows into the
virtual machine (you never have to actually show the Windows desktop per se)
and then launch applications which are exported to and framed by the X11
window manager. It should "feel" like Windows applications are running on
your Linux desktop at good speed with full compatability (as far as is
afforded by the virtual machine).

:o)

Jamie Burns.

----- Original Message ----- 
From: "Fabrice Bellard" <fabrice.bellard@free.fr>
To: <qemu-devel@nongnu.org>
Sent: Monday, February 16, 2004 12:07 AM
Subject: [Qemu-devel] Code Copy / New Linux boot code


> Just to give more information about the next commits:
>
> 1) I finally added a hand coded x86 to x86 translator. It means that
> qemu-fast has now close to native performances on x86. Who spoke about
> PC virtualization ? :-)
>
> The x86 to x86 translator is limited to flat 32 bit mode and it does not
> support floating point (yet !). If the translator cannot handle a given
> instruction, then the "portable" translator is used as a fallback.
>
> 2) qemu-fast is being enhanced to run unpatched OSes and to support VESA
> VBE graphics.
>
> The limitations of qemu-fast are that if data at addresses >= 0xc0000000
> is used, then soft MMU is used in the corresponding translated block.
>
> Moreover, the guest user code has write access to the guest OS code and
> also to the host QEMU code. It means that qemu-fast is not safe. I don't
> know yet what is the best way to solve this issue.
>
> 3) A new and simpler Linux kernel loader has been added (for the
> '-kernel' command line option). Now the PC BIOS and the VGA BIOS are run
> before running the kernel, which gives exactly the same behavior as if
> the kernel was booted normally.
>
> Fabrice.
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel