qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] About qemu emulation speed (a question) and supported O


From: Mark Williamson
Subject: Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS
Date: Wed, 14 Sep 2005 18:53:18 +0100
User-agent: KMail/1.8

Two side footnotes to your comprehensive explanation:

1) with the SKAS host kernel patch you don't have to ptrace the "guest" 
processes and performance (and security) is improved quite a bit, I 
understand.

2) UML is currently being ported to run in ring 0.  Why?  Not for running on 
native hardware, but to run in VMX non-root mode on VT processors.  This 
enables a host kernel module to use the VT extensions to run the UML guest 
with much better speed.  The guest kernel can then easily take syscalls 
itself, manange its own page tables, etc.  More details in the procedings of 
this year's Ottawa Linux Symposium.

I think these both correspond to your points a) and b).  Another neat thing 
UML can do by running in a process is directly mount host filesystems using 
the HostFS driver.  Doing this in Xen is proving much harder (although my 
work is aiming for a slightly different set of functionality).

Cheers,
Mark

On Wednesday 14 September 2005 16:47, Henrik Nordstrom wrote:
> On Wed, 14 Sep 2005, Jim C. Brown wrote:
> > Not familar with L4ka. I don't believe that UML does virtualization, it
> > simply runs linux code 'as is' but intercepts calls to the kernel.
>
> UML does not do hardware virtualization. UML is a special architecture for
> the Linux kernel allowing Linux to run ontop of Linux. It does so by using
> it's own drivers and memory management, intercepting Linux system calls
> and playing with the page tables. All executed code is native in ring 3
> (even the kernel parts, just a different memory mapping when the kernel
> code executes). The UML Linux kernel does not access any hardware, instead
> it provides drivers for "simulated" harddrives, serial ports etc
> translating these into suitable user-space actions on the host (i.e.
> read/writes to a block device is translated to read/writes in a file on
> the host, etc.. at the kernel driver level, not by hardware
> simulation/emulation/partitioning).
>
> The UML Linux kernel is running as a normal application on the host. But
> within the process virtual memory maps is provided for user-space
> applications and any systems calls made by user-space applications running
> there is intercepted with help from the syscall tracing facilities of the
> host and instead acted on by the UML Linux kernel.
>
> In theory UML should be able to run at native speed as there is no
> virtualization, translation or emulation involved, but as always there is
> overhead from various sources. To gain better performance the UML people
> is playing with
>
>    a) More efficient management of multiple page tables for the same host
> process, allowing efficient switches between different contexts of the
> same process (kernel mode, user-space processes within UML etc).
>
>    b) More efficient methods intercepting system calls.
>
>    c) more efficient I/O drivers, mainly for block device access.
>
> Regards
> Henrik
>
>
> _______________________________________________
> Qemu-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel




reply via email to

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