[Qemu-devel] QEMU extension

[Qemu-devel] QEMU extension

[G Portokalidis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I'm writing concerning a possible use for qemu in a project related to
network security.

I'm looking for an emulator where I could load an entire (recent) OS,
like Linux 2.6 or Windows XP and run multiple, potentially CPU
intensive, services (IIS, Apache, MySQL, etc).

For the needs of the project I need to be able to know every instruction
executed by the guest OS, and run custom code whenever an instruction of
particular interest appears (doesn't really matter whether it's C or
x86, but preferably the first).

So my first question is whether we could run Linux 2.6 and most
importantly Windows XP on qemu without stability issues. Second, does
the current design of qemu allows me to implement the functionality
described in the above paragraph.

The developed code will be released under GPL and could be later
incorporated in qemu if it provides commonly desired functionality.

Finally, what's the performance of qemu compared with a PC (how many
times slower)?

Cheers,
Georgios Portokalidis

- --
Georgios Portokalidis
Vrije Universiteit
FEW, Department of Computer Science
W&N, Room P471     
De Boelelaan 1081a                              
1081 HV  Amsterdam      
+31(0)20-5987726                     

VU-disclaimer: www.vu.nl/e-maildisclaimer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iEYEARECAAYFAkKV9X0ACgkQbZp0oqIQNPoi5wCeLqx4NWflCldTaOnywwp19+jG
jWIAn3h2Kk0uCWS93IKP7pX33m+zj73q
=mjLO
-----END PGP SIGNATURE-----

Re: [Qemu-devel] QEMU extension

[Paul Brook]

On Thursday 26 May 2005 17:12, G Portokalidis wrote:
> Hello,
>
> I'm writing concerning a possible use for qemu in a project related to
> network security.
>
> I'm looking for an emulator where I could load an entire (recent) OS,
> like Linux 2.6 or Windows XP and run multiple, potentially CPU
> intensive, services (IIS, Apache, MySQL, etc).
>
> For the needs of the project I need to be able to know every instruction
> executed by the guest OS, and run custom code whenever an instruction of
> particular interest appears (doesn't really matter whether it's C or
> x86, but preferably the first).
>
> So my first question is whether we could run Linux 2.6 and most
> importantly Windows XP on qemu without stability issues. 

Linux works fine. For windows XP it seems to depend which windows version 
you're using. Some versions work ok, others don't.

> Second, does 
> the current design of qemu allows me to implement the functionality
> described in the above paragraph.

You may be better using bochs. That has instrumentation hooks that should 
allow you do do what you want. boch is significantly slower that qemu, but if 
you're instrumenting a significant number of instructions it's going to be 
dog slow anyway.

Qemu already has infrastructure for a gdb ICE connection. You could probably 
hack that to do what you want.

> Finally, what's the performance of qemu compared with a PC (how many
> times slower)?

It's generally 10-15x slower than the host.

Paul

Re: [Qemu-devel] QEMU extension

[Mike Swanson]

Though with KQEMU (for Linux and FreeBSD hosts only), you can run
x86-on-x86 emulation at native speed.
-- 
Mike

Re: [Qemu-devel] QEMU extension

[Paul Brook]

On Thursday 26 May 2005 17:46, Mike Swanson wrote:
> Though with KQEMU (for Linux and FreeBSD hosts only), you can run
> x86-on-x86 emulation at native speed.

Which is entirely irrelevant because:
(a) You can't do the required instrumentation with a virtualization based 
solution like kqemu/qvm86.
(b) kqemu is a closed-source binary released under a proprietary licence, so 
wouldn't be usable in a GPL project.

Paul

Re: [Qemu-devel] QEMU extension

[John Davidorff Pell]

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

Is kQemu closed source? I thought it was just not a GPL compatible  
license. Don't you have to build it with your qemu tree??

If you get the source code from a freely downloadable archive, then  
its most certainly not closed source...

Or maybe I'm totally confused and kQemu is binary-only. :-)

JP

On 26 May 2005, at 09:58, Paul Brook wrote:

> (b) kqemu is a closed-source binary released under a proprietary  
> licence, so
> wouldn't be usable in a GPL project.



----
It's all fun and games 'til someone writes to a NULL pointer!



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2545 bytes --]

Re: [Qemu-devel] QEMU extension

[John Davidorff Pell]

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

Well, it turns out I am totally confused. I checked online and -- lo  
and behold -- the kqemu tar is just an elf binary.... :-(

I stand corrected (by myself)

JP

On 31 May 2005, at 00:00, John Davidorff Pell wrote:

> Is kQemu closed source? I thought it was just not a GPL compatible  
> license. Don't you have to build it with your qemu tree??
>
> If you get the source code from a freely downloadable archive, then  
> its most certainly not closed source...
>
> Or maybe I'm totally confused and kQemu is binary-only. :-)
>
> JP
>
> On 26 May 2005, at 09:58, Paul Brook wrote:
>
>
>> (b) kqemu is a closed-source binary released under a proprietary  
>> licence, so
>> wouldn't be usable in a GPL project.
>>
>
>
>
> ----
> It's all fun and games 'til someone writes to a NULL pointer!
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>



--
if (message.signature==FUNNY) steal(message.signature); else  
message=message->next;



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2545 bytes --]

Re: [Qemu-devel] QEMU extension

[Damien "tuX" THEBAULT]

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

Le mardi 31 mai 2005 à 00:00 -0700, John Davidorff Pell a écrit :
> Is kQemu closed source? I thought it was just not a GPL compatible  
> license. Don't you have to build it with your qemu tree??
> 
> If you get the source code from a freely downloadable archive, then  
> its most certainly not closed source...
> 
> Or maybe I'm totally confused and kQemu is binary-only. :-)

kqemu IS binary-only :
http://fabrice.bellard.free.fr/qemu/qemu-accel.html


-- 
Damien Thebault
public keys on http://pgp.mit.edu

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Qemu-devel] QEMU extension

[G Portokalidis]

I think I'm gonna go ahead with Qemu. Bochs seems to be to slow for my purpose.
I was wondering if you know which windows XP versions have been know to work?
Also do you have any performance metrics on popular applications
runing under qemu(ex. apache)? I guess it's in the usenix paper, but i
can't download it.

George

On 5/26/05, Paul Brook <paul@codesourcery.com> wrote:
> On Thursday 26 May 2005 17:12, G Portokalidis wrote:
> > Hello,
> >
> > I'm writing concerning a possible use for qemu in a project related to
> > network security.
> >
> > I'm looking for an emulator where I could load an entire (recent) OS,
> > like Linux 2.6 or Windows XP and run multiple, potentially CPU
> > intensive, services (IIS, Apache, MySQL, etc).
> >
> > For the needs of the project I need to be able to know every instruction
> > executed by the guest OS, and run custom code whenever an instruction of
> > particular interest appears (doesn't really matter whether it's C or
> > x86, but preferably the first).
> >
> > So my first question is whether we could run Linux 2.6 and most
> > importantly Windows XP on qemu without stability issues.
> 
> Linux works fine. For windows XP it seems to depend which windows version
> you're using. Some versions work ok, others don't.
> 
> > Second, does
> > the current design of qemu allows me to implement the functionality
> > described in the above paragraph.
> 
> You may be better using bochs. That has instrumentation hooks that should
> allow you do do what you want. boch is significantly slower that qemu, but if
> you're instrumenting a significant number of instructions it's going to be
> dog slow anyway.
> 
> Qemu already has infrastructure for a gdb ICE connection. You could probably
> hack that to do what you want.
> 
> > Finally, what's the performance of qemu compared with a PC (how many
> > times slower)?
> 
> It's generally 10-15x slower than the host.
> 
> Paul
>