[Qemu-devel] About qemu emulation speed (a question) and supported OS

[Qemu-devel] About qemu emulation speed (a question) and supported OS

[Alexandre Leclerc]

Hi all,

I'm new to qemu and my question is simple and is probably due to my
ignorance. If I compare qemu and vmware, there is a great deal of
emulation speed differences.

- Is it because of what qemu is? (i.e. it is a full emulator of many
platforms, etc. Meaning that vmware is probably only specialised for
x86...)
- If no, is it possible that one day qemu reaches the speed of vmware?

I'm just asking because I'll probably need an emulator for a host
linux guest winxp in few time. This is for a production environment
and to develop in windows (so programming in the vm all day long, so
speed is very important since it impacts productivity.) So I must know
if it is better for me to buy a vmware licence.

By the way, I succesfully installed XPHome on 0.7.2 from the boot CD.
It took 3 about hours for the installation and it is globally slow to
run (host is Mandriva LE 2005, P4 2.4Ghz). If someone is interested in
updating the stat on the web site (supported guest OS). I really did
nothing special. Made an ISO, created qcow hd, FDISK-ed / FORMAT-ed hd
from freedos bood disk.

Best regards.

-- 
Alexandre Leclerc

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

[Adrian Smarzewski]

Alexandre Leclerc wrote:
> I'm new to qemu and my question is simple and is probably due to my
> ignorance. If I compare qemu and vmware, there is a great deal of
> emulation speed differences.

Did you try kqemu or qvm86?

-- 
Pozdrowienia,
Adrian Smarzewski

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

[Alexandre Leclerc]

On 9/13/05, Adrian Smarzewski <adrian@kadu.net> wrote:
> Alexandre Leclerc wrote:
> > I'm new to qemu and my question is simple and is probably due to my
> > ignorance. If I compare qemu and vmware, there is a great deal of
> > emulation speed differences.
> 
> Did you try kqemu or qvm86?

Yes, with kqemu.

-- 
Alexandre Leclerc

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

[Jim C. Brown]

On Tue, Sep 13, 2005 at 08:36:29AM -0400, Alexandre Leclerc wrote:
> Hi all,
> 
> I'm new to qemu and my question is simple and is probably due to my
> ignorance. If I compare qemu and vmware, there is a great deal of
> emulation speed differences.
> 
> - Is it because of what qemu is? (i.e. it is a full emulator of many
> platforms, etc. Meaning that vmware is probably only specialised for
> x86...)

Yes. qemu does dynamic translation, which allows for arbituary combinations
(PPC host and x86 guest, x86 host and PPC guest, SPARC host and PPC guest,
etc.) but is also slower than running code via virtualization, which is what
VMware does (virtualization only works when host and guest are same, e.g.
x86 host and x86 guest or PPC host and PPC guest; it's also not possible (or
at least very hard) to generalize this so virtualizers tend to be tied to a
single computer arch).

> - If no, is it possible that one day qemu reaches the speed of vmware?
> 

qemu itself? Nope.

kqemu/qvm86 don't have this limitation though. Fabrice had said that he wants
kqemu to be able to do total virtualization (both kernel and userland bits);
basically all the translation code of qemu would be left unused but the hardware
emulation would still be shared.

(I'm not sure why Fabrice wants kqemu to do total virtualization: possibly he
wants to turn it into a commercial product.)

> I'm just asking because I'll probably need an emulator for a host
> linux guest winxp in few time. This is for a production environment
> and to develop in windows (so programming in the vm all day long, so
> speed is very important since it impacts productivity.) So I must know
> if it is better for me to buy a vmware licence.
> 

VMware has good speed gains for Windows guests because of the VMware tools
package - it uses custom guest drivers which allow it to get a huge speedup
by avoiding the burden of emulated I/O. qemu doesn't do this, and while it isn't
too difficult to add, I doubt anyone will bother in the near future.

I use qemu (sans kqemu/qvm86) to program in Windows. I use 2000, I found
XP unbearably slow (but the speed would be improved when using kqemu). I find
that the speed of using cygwin gcc in win2000 to be acceptable, but slower than
linux/gnu gcc. It would be much faster with kqemu but I don't know how much.

The nice thing about FOSS: you can give it a test run to see if its fast enough
for your purpose or not.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Anthony Liguori]

Jim C. Brown wrote:

>>- If no, is it possible that one day qemu reaches the speed of vmware?
>>
>>    
>>
>
>qemu itself? Nope.
>
>kqemu/qvm86 don't have this limitation though. Fabrice had said that he wants
>kqemu to be able to do total virtualization (both kernel and userland bits);
>basically all the translation code of qemu would be left unused but the hardware
>emulation would still be shared.
>  
>
I reckon this means taking advantage of VT and Pacifica when they're 
available so the kernel code can be safely run on bare metal.

FWIW, Xen is already using QEMU in this way.  It would be very neat to 
see this technique applied to a Type II VMM.

Regards,

Anthony Liguori

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

[Jim C. Brown]

On Tue, Sep 13, 2005 at 09:58:11AM -0500, Anthony Liguori wrote:
> Jim C. Brown wrote:
> 
> >Fabrice had said that he > >wants
> >kqemu to be able to do total virtualization (both kernel and userland > >bits);
> >basically all the translation code of qemu would be left unused but the 
> >hardware> >emulation would still be shared.
> > 
> >
> I reckon this means taking advantage of VT and Pacifica when they're 
> available so the kernel code can be safely run on bare metal.
> 

No, I got the impression that Fabrice was taking about virtualization the way
VMware, old plex86, and vmbear (new FOSS x86 virtualizer in the works) do it.

So it'll work w/o needing a 64bit chip.

> FWIW, Xen is already using QEMU in this way.  It would be very neat to 
> see this technique applied to a Type II VMM.
> 

Do you have any details on this?

> Regards,
> 
> Anthony Liguori
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Mark Williamson]

> No, I got the impression that Fabrice was taking about virtualization the
> way VMware, old plex86, and vmbear (new FOSS x86 virtualizer in the works)
> do it.
>
> So it'll work w/o needing a 64bit chip.

I hadn't seen vmbear, looks interesting...  Full virtualisation on vanilla x86 
would be really handy (until everyone is running VT or SVM chips).  It 
requires a brave coder, though - some of that stuff is going to be pretty 
entertaining to write!

> > FWIW, Xen is already using QEMU in this way.  It would be very neat to
> > see this technique applied to a Type II VMM.
>
> Do you have any details on this?

Lightning overview -

In Xen we have no host / guest: Xen runs on the bare metal and hosts all the 
OSes in the system.  One of them "Domain 0" is privileged to access the 
hardware devices - it normally uses explicit inter-VM communication to supply 
device services to other guests (using Xen-specific device drivers).  This is 
OK for Xen-native guests, since they're explicitly aware of the hypervisor.  
For fully virtualised guests we need a different approach.

We're not attempting to make full virtualisation work on vanilla x86 - you 
need a virtualisation-aware chip.  Domain 0 must still be a "native" 
Xen-aware OS.  For unprivileged guests, Xen handles the low-level work of 
managing its shadow pagetables, trapping and (perhaps) emulating privileged 
instructions, etc.  Xen doesn't contain any device virtualisation code, so 
instead it passes up IO port / IO memory accesses to the "device model"  
which runs as a daemon process in domain 0.

The device model daemon receives these IO port accesses and feeds them to the 
"device models".  These run in userspace, emulating real PCI hardware using 
the QEmu code (+ one extra network device model, IIRC).  They perform the 
appropriate emulation actions, do any necessary IO, then feed a response to 
the IO instruction back to Xen.

This way, the device models are kept out of Xen, however it's a bit 
inefficient to have so many context switches.  Work is planned (underway?) to 
restructure the device models, porting them to run in specialised virtual 
machines that will "shadow" the real VMs and provide IO services.

(side note: originally Bochs code supplied the device models, QEmu replaced it 
later on because it was technically a better fit)

Does that all make sense?  I know I've been a bit brief - do ask if anything 
wasn't sufficiently well explained.

Cheers,
Mark

> > Regards,
> >
> > Anthony Liguori
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel

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

[Anthony Liguori]

Jim C. Brown wrote:

>On Tue, Sep 13, 2005 at 09:58:11AM -0500, Anthony Liguori wrote:
>  
>
>>Jim C. Brown wrote:
>>
>>    
>>
>>>Fabrice had said that he > >wants
>>>kqemu to be able to do total virtualization (both kernel and userland > >bits);
>>>basically all the translation code of qemu would be left unused but the 
>>>hardware> >emulation would still be shared.
>>>
>>>
>>>      
>>>
>>I reckon this means taking advantage of VT and Pacifica when they're 
>>available so the kernel code can be safely run on bare metal.
>>
>>    
>>
>
>No, I got the impression that Fabrice was taking about virtualization the way
>VMware, old plex86, and vmbear (new FOSS x86 virtualizer in the works) do it.
>  
>
The x86 cannot be "virtualized" in the Popek/Goldberg sense, so there's 
a couple of fast emulation techniques that are possible.  Other than a 
hand coded dynamic translator, I reckon qemu + kqemu is about as good as 
it can get (unless I'm missing something here).  Do you have

There are a couple of interesting paravirtualization techniques too.  
There's the Xen approach (really fast, but very invasive), the L4ka 
afterburning (theoritically close to as fast, but less invasive), and 
then of course the extremes like UML.

>>FWIW, Xen is already using QEMU in this way.  It would be very neat to 
>>see this technique applied to a Type II VMM.
>>
>>    
>>
>
>Do you have any details on this?
>  
>
Mark did a really good job of summarizing the current architecture.

Regards,

Anthony Liguori

>>Regards,
>>
>>Anthony Liguori
>>
>>
>>_______________________________________________
>>Qemu-devel mailing list
>>Qemu-devel@nongnu.org
>>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>>    
>>
>
>  
>

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

[Mark Williamson]

> >No, I got the impression that Fabrice was taking about virtualization the
> > way VMware, old plex86, and vmbear (new FOSS x86 virtualizer in the
> > works) do it.
>
> The x86 cannot be "virtualized" in the Popek/Goldberg sense, so there's
> a couple of fast emulation techniques that are possible.  Other than a
> hand coded dynamic translator, I reckon qemu + kqemu is about as good as
> it can get (unless I'm missing something here).  Do you have

Well, VMware does manage direct execution of some kernel code, I believe.  
VMware's real super-cunningness is doing this as much as they can, instead of 
emulating all the stuff.  That said, I think with suitable optimisations 
emulating all the kernel code could be acceptable.

The unfortunate thing is that the guest can still tell it's in a VMware 
machine (I'm not clear how) so it's not really *full* virtualisation, it's 
just about epsilon away from it :-)  VT / SVM will solve this properly.

> There are a couple of interesting paravirtualization techniques too.
> There's the Xen approach (really fast, but very invasive), the L4ka
> afterburning (theoritically close to as fast, but less invasive), and
> then of course the extremes like UML.

The original L4 port of Linux was pretty hard-core stuff.  I understand later 
L4 developments made native ports easier.  The afterburner stuff seems to be 
the next generation of coolness!

The afterburning is really neat stuff :-)  You can use one kernel for native, 
L4 guest and Xen guest.  The kernel actually does some of the virtualisation 
work itself by doing (tasteful levels of) self-rewriting / device emulation 
on its own.  You can run normal device drivers, etc.  This has to be assisted 
by some compiler tool-chain stuff that allows the runtime "wedge" to do its 
job.

They have a (crazy but cool) idea that they'll one day be able to live-migrate 
(i.e. without more than a few hundred ms downtime) virtual machines between 
L4 hypervisors and Xen hypervisors.

Cheers,
Mark

> >>FWIW, Xen is already using QEMU in this way.  It would be very neat to
> >>see this technique applied to a Type II VMM.
> >
> >Do you have any details on this?
>
> Mark did a really good job of summarizing the current architecture.
>
> Regards,
>
> Anthony Liguori
>
> >>Regards,
> >>
> >>Anthony Liguori
> >>
> >>
> >>_______________________________________________
> >>Qemu-devel mailing list
> >>Qemu-devel@nongnu.org
> >>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

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

[Anthony Liguori]

Mark Williamson wrote:

>>>No, I got the impression that Fabrice was taking about virtualization the
>>>way VMware, old plex86, and vmbear (new FOSS x86 virtualizer in the
>>>works) do it.
>>>      
>>>
>>The x86 cannot be "virtualized" in the Popek/Goldberg sense, so there's
>>a couple of fast emulation techniques that are possible.  Other than a
>>hand coded dynamic translator, I reckon qemu + kqemu is about as good as
>>it can get (unless I'm missing something here).  Do you have
>>    
>>
>
>Well, VMware does manage direct execution of some kernel code, I believe.  
>VMware's real super-cunningness is doing this as much as they can, instead of 
>emulating all the stuff.  That said, I think with suitable optimisations 
>emulating all the kernel code could be acceptable.
>
>The unfortunate thing is that the guest can still tell it's in a VMware 
>machine (I'm not clear how) so it's not really *full* virtualisation, it's 
>just about epsilon away from it :-)  VT / SVM will solve this properly.
>  
>
I reckon kqemu has this same problem... Technically, even in ring 3, if 
you run natively, you violate the Popek/Goldberg requirements because of 
cpuid.  It's just not possible to trap it but it shouldn't matter for 
most software.

>They have a (crazy but cool) idea that they'll one day be able to live-migrate 
>(i.e. without more than a few hundred ms downtime) virtual machines between 
>L4 hypervisors and Xen hypervisors.
>  
>
Yeah, how cool is that :-)

Regards,

Anthony Liguori

>Cheers,
>Mark
>
>  
>
>>>>FWIW, Xen is already using QEMU in this way.  It would be very neat to
>>>>see this technique applied to a Type II VMM.
>>>>        
>>>>
>>>Do you have any details on this?
>>>      
>>>
>>Mark did a really good job of summarizing the current architecture.
>>
>>Regards,
>>
>>Anthony Liguori
>>
>>    
>>
>>>>Regards,
>>>>
>>>>Anthony Liguori
>>>>
>>>>
>>>>_______________________________________________
>>>>Qemu-devel mailing list
>>>>Qemu-devel@nongnu.org
>>>>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>>>        
>>>>
>>_______________________________________________
>>Qemu-devel mailing list
>>Qemu-devel@nongnu.org
>>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>    
>>
>
>  
>

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

[Mike Swanson]

Well, VMware guests can recognise that they're in a VM because the
software contains a backdoor INT function, mainly used by VMware Tools
for things like Shared Folders and host-controlled mouse cursors
insides guests. I don't quite remember what the function was for
VMware's backdoor, but you can find info at vmware's back:
http://chitchat.at.infoseek.co.jp/vmware/

-- 
Mike

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

[Jim C. Brown]

On Tue, Sep 13, 2005 at 11:27:39PM -0500, Anthony Liguori wrote:
> I reckon kqemu has this same problem... Technically, even in ring 3, if 
> you run natively, you violate the Popek/Goldberg requirements because of 
> cpuid.  It's just not possible to trap it but it shouldn't matter for 
> most software.
> 

It is possible to trap it, in a sense. You just read ahead and replace the
cpuid instruction with something else.

Ugly, but doable.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Anthony Liguori]

Jim C. Brown wrote:

>On Tue, Sep 13, 2005 at 11:27:39PM -0500, Anthony Liguori wrote:
>  
>
>>I reckon kqemu has this same problem... Technically, even in ring 3, if 
>>you run natively, you violate the Popek/Goldberg requirements because of 
>>cpuid.  It's just not possible to trap it but it shouldn't matter for 
>>most software.
>>
>>    
>>
>
>It is possible to trap it, in a sense. You just read ahead and replace the
>cpuid instruction with something else.
>  
>
You can't readahead beyond a basic block.  Taking a trap for each basic 
block and translating the block is what QEMU does.

Regards,

Anthony Liguori

>Ugly, but doable.
>
>  
>

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

[Jim C. Brown]

On Wed, Sep 14, 2005 at 01:46:58PM -0500, Anthony Liguori wrote:
> You can't readahead beyond a basic block.  Taking a trap for each basic 
> block and translating the block is what QEMU does.
> 

No, QEMU translates everything from guest machine code into its internal codes.

I'm talking about using read ahead to change only those instructions which cause
problems, and replacing them with instructions that are from the same instruction
set

I suppose you could call that emulation in a sense (as ur emulating the problematic
instructions with other ones that create the behavior you need) but it is not
the same as what QEMU currently does.

Of course, VMware also emulates hardware, but you'd have to do that no matter
what technique you use and it is a separate issue from emulation vs translation
vs virtualization. (Theoretically VMware could just use a HAL layer like Xen
does (or the newer plex86 did) and still be a virtualizer, but then it wouldn't
work with unmodified guest OSes.)

> Regards,
> 
> Anthony Liguori

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Jim C. Brown]

On Tue, Sep 13, 2005 at 09:48:01PM -0500, Anthony Liguori wrote:
> Jim C. Brown wrote:
> 
> The x86 cannot be "virtualized" in the Popek/Goldberg sense, so there's 
> a couple of fast emulation techniques that are possible.  Other than a 
> hand coded dynamic translator, I reckon qemu + kqemu is about as good as 
> it can get (unless I'm missing something here). 

qvm86 only virtualizes ring3 code. It doesn't handle ring 0 (e.g. kernel) at all.

VMware handles kernel code. You are right that x86 code can't be 100% virtualized
(even at the userland level) but VMware uses a lot of nasty disgusting tricks
in order to work around them. (For example, playing with shadow pagetables
so that a page of modified code is run but if the code tries to inspect itself
it sees another (unexecuted) page that contains the original code.)

Basically the original code is 'fixed' so it runs in ring 3, but this is still
faster than translation.

> Do you have
> 

Do I have what?

> There are a couple of interesting paravirtualization techniques too.  
> There's the Xen approach (really fast, but very invasive), the L4ka 
> afterburning (theoritically close to as fast, but less invasive), and 
> then of course the extremes like UML.
> 

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.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Henrik Nordstrom]

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

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

[Mark Williamson]

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
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

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

[John R. Hogerhuis]

On Wed, 2005-09-14 at 09:37 -0400, Jim C. Brown wrote:

> VMware handles kernel code. You are right that x86 code can't be 100% virtualized
> (even at the userland level) but VMware uses a lot of nasty disgusting tricks
> in order to work around them. (For example, playing with shadow pagetables
> so that a page of modified code is run but if the code tries to inspect itself
> it sees another (unexecuted) page that contains the original code.)
> 

Why disgusting?

Seems like a smart implementation given the options at hand.

Perhaps you meant disgusting because the Intel architecture forces a
virtualizer to handle a bunch of corner cases like this.

-- John.

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

[Jim C. Brown]

On Wed, Sep 14, 2005 at 10:18:24AM -0700, John R. Hogerhuis wrote:
> Why disgusting?
> 
> Perhaps you meant disgusting because the Intel architecture forces a
> virtualizer to handle a bunch of corner cases like this.
> 

That is exactly what I mean.

> -- John.
> 


-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Mark Williamson]

> > There are a couple of interesting paravirtualization techniques too.
> > There's the Xen approach (really fast, but very invasive), the L4ka
> > afterburning (theoritically close to as fast, but less invasive), and
> > then of course the extremes like UML.
>
> 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.

I don't want to put words in Anthony's mouth but I usually see UML as a rather 
(very) extreme case of paravirtualisation that barely preserves the 
underlying architecture's characteristics; I'm guessing that's what he 
meant...

Cheers,
Mark

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

[Karl Magdsick]

> VMware handles kernel code. You are right that x86 code can't be 100% virtualized
> (even at the userland level) but VMware uses a lot of nasty disgusting tricks
> in order to work around them. (For example, playing with shadow pagetables
> so that a page of modified code is run but if the code tries to inspect itself
> it sees another (unexecuted) page that contains the original code.)

I take it self-modifying kernel code would have serious issues.

I seem to recall my attempts to run v2OS (which uses a self-modifying
assembly code boot sequence) inside VMWare crashing badly circa 2001.


-Karl

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

[Mark Williamson]

> I take it self-modifying kernel code would have serious issues.

Seems likely :-)  With hardware support, making things like this work should 
be *much* easier.

> I seem to recall my attempts to run v2OS (which uses a self-modifying
> assembly code boot sequence) inside VMWare crashing badly circa 2001.

Can QEmu handle self-modifying code?  I.e. can it invalidate the translation 
cache appropriately?

Cheers,
Mark