[Qemu-devel] About performance of qemu-system-arm

[Qemu-devel] About performance of qemu-system-arm

[PianoPan]

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

Hello, everyone,



Now, I'm planning to use Qemu as our mobile device emulator (ARM). Before
our development, I want to confirm performance of it. I use packages from
http://folks.o-hand.com/richard/qemu.html to build the evaluation
environment, but performance of Linux in Qemu is too slow. It uses about one
hour to boot GUI system.



Can anybody tell me this performance is proper or not?

Best regards!
Piano Pan

[-- Attachment #2: Type: text/html, Size: 745 bytes --]

[Qemu-devel] Re: About performance of qemu-system-arm

[Ross Burton]

On Wed, 2006-12-13 at 16:09 +0800, PianoPan wrote:
> Now, I'm planning to use Qemu as our mobile device emulator (ARM).
> Before our development, I want to confirm performance of it. I use
> packages from http://folks.o-hand.com/richard/qemu.html to build the
> evaluation environment, but performance of Linux in Qemu is too slow.
> It uses about one hour to boot GUI system. 
>
> Can anybody tell me this performance is proper or not?

On my laptop -- a Intel Core Duo 1.8GHz -- I can boot an OpenEmbedded
image (with X, matchbox, udev, etc) in a minute or so.

Ross
-- 
Ross Burton                                 mail: ross@burtonini.com
                                          jabber: ross@burtonini.com
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

Re: [Qemu-devel] About performance of qemu-system-arm

[Màrius Montón]

[-- Attachment #1.1: Type: text/plain, Size: 1297 bytes --]

Hi,

I've used distro from http://www.aurel32.net/info/debian_arm_qemu.php.

It's working fine (about 1 minute to boot in my PC).

regards,

Màrius

PianoPan wrote:
> Hello, everyone,
>
>  
>
> Now, I'm planning to use Qemu as our mobile device emulator (ARM).
> Before our development, I want to confirm performance of it. I use
> packages from http://folks.o-hand.com/richard/qemu.html to build the
> evaluation environment, but performance of Linux in Qemu is too slow.
> It uses about one hour to boot GUI system.
>
>  
>
> Can anybody tell me this performance is proper or not?
>
> Best regards!
>
> Piano Pan
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>   

-- 
Màrius Montón i Macián   marius.monton@uab.cat
<mailto:marius.monton@uab.cat>  http://cephis.uab.es
<http://www.mariusmonton.name>
Hardware Engineer
CEPHIS
Centre de Prototips i Solucions Hardware-Software
Dep. Microelectrònica i Sistemes Electrònics
ETSE - Universitat Autònoma de Barcelona (UAB) 	Phone: +34 935 813 534
Fax: +34 935 813 033
QC-2090D. ETSE. Campus UAB.
080193 Bellaterra



[-- Attachment #1.2: Type: text/html, Size: 3072 bytes --]

[-- Attachment #2: marius.monton.vcf --]
[-- Type: text/x-vcard, Size: 440 bytes --]

begin:vcard
fn;quoted-printable:M=C3=A0rius Mont=C3=B3n
n;quoted-printable;quoted-printable:Mont=C3=B3n;M=C3=A0rius
org;quoted-printable:CEPHIS;Microelectr=C3=B2nica i Sistemes Electronics
adr:Campus de la UAB;;QC-2090D, ETSE;Bellaterra;Barcelona;08193;Spain
email;internet:marius.monton@uab.es
title:HW Engineer
tel;work:+34935813534
tel;fax:+34935813033
x-mozilla-html:TRUE
url:http://cephis.uab.es
version:2.1
end:vcard

Re: [Qemu-devel] About performance of qemu-system-arm

[Martin Guy]

2006/12/13, PianoPan <pianopan@gmail.com>:
> performance of Linux in Qemu is too slow. It
> uses about one hour to boot GUI system.

During development work this summer at one point I experienced an
immense slowdown of QEMU - from 63 bogomips to 1 or 2 on a 400MHz
Pentium. The problem went away when I upgraded the ARM linux kernel
that QEMU was running from 2.6.16 to 2.6.16-rc3 and the problem has
not come back with later versions (.17 .18)

      M

Re: [Qemu-devel] About performance of qemu-system-arm

[PianoPan]

Hi   Màrius:

>  It's working fine (about 1 minute to boot in my PC).

Did you mean that 1 minute to boot the X system?

Regards !

Piano Pan

On 12/13/06, Màrius Montón <marius.monton@uab.es> wrote:
>
>  Hi,
>
>  I've used distro from http://www.aurel32.net/info/debian_arm_qemu.php.
>
>  It's working fine (about 1 minute to boot in my PC).
>
>  regards,
>
>  Màrius
>
>  PianoPan wrote:
>
> Hello, everyone,
>
>
>
> Now, I'm planning to use Qemu as our mobile device emulator (ARM). Before our development, I want to confirm performance of it. I use packages from http://folks.o-hand.com/richard/qemu.html to build the evaluation environment, but performance of Linux in Qemu is too slow. It uses about one hour to boot GUI system.
>
>
>
> Can anybody tell me this performance is proper or not?
>
> Best regards! Piano Pan
>    ________________________________

> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
> --
>
>        Màrius Montón i Macián    marius.monton@uab.cat         http://cephis.uab.es
>        Hardware Engineer
>         CEPHIS
>        Centre de Prototips i Solucions Hardware-Software
>  Dep. Microelectrònica i Sistemes Electrònics
>  ETSE - Universitat Autònoma de Barcelona (UAB)         Phone: +34 935 813 534
>         Fax: +34 935 813 033
>         QC-2090D. ETSE. Campus UAB.
>         080193 Bellaterra
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
>

[Qemu-devel] qemu-system-* using mmap?

[Tim Olson]

I am using qemu 0.8.2 built from source.  In the qemu technical 
documentation for features under full system emulation, it says:

"QEMU can either use a full software MMU for maximum portability or use 
the host system call mmap() to simulate the target MMU."

However, I cannot find a way to build a full system simulator which 
does not define SOFTMMU -- in fact, the configure parameters 
"--disable-system" and "--enable-system" directly control the softmmu 
switch.  There are some mmap() calls in the kqemu code, but to use that 
requires full kqemu support code in the kernel.

I think there is a big performance hit using the software mmu, as each 
target load or store instruction is expanded into 20-30 host 
instructions to perform the translation.  Is there a way to build the 
qemu-system-* emulators using the mmap() feature mentioned in the 
documentation?

	-- Tim Olson

Re: [Qemu-devel] About performance of qemu-system-arm

[Martin Guy]

2006/12/13, Martin Guy <martinwguy@yahoo.it>:
> 2006/12/13, PianoPan <pianopan@gmail.com>:
> > performance of Linux in Qemu is too slow. It
> > uses about one hour to boot GUI system.
>
> During development work this summer at one point I experienced an
> immense slowdown of QEMU - from 63 bogomips to 1 or 2

Sorry I forgot to say, that was with qemu-system-arm 0.8.2

The sort of performance you should be seeing is, for example, a 2GHz
AMD or a 4GHz Intel giving the same realtime speed as a 100-200MHz
ARM.

    M

Re: [Qemu-devel] About performance of qemu-system-arm

[Màrius Montón]

[-- Attachment #1.1: Type: text/plain, Size: 2644 bytes --]

Hi,

Sorry for my previous short answer:

It take about 1 minute to boot console login.
I don't have tested X system, but I suspect it can spent no more than 10
minutes (probably less, but I don't know)

I use "qemu-system-arm -M versatilepb ..."

Regards,

Marius

PianoPan wrote:
> Hi   Màrius:
>
>>  It's working fine (about 1 minute to boot in my PC).
>
> Did you mean that 1 minute to boot the X system?
>
> Regards !
>
> Piano Pan
>
> On 12/13/06, Màrius Montón <marius.monton@uab.es> wrote:
>>
>>  Hi,
>>
>>  I've used distro from http://www.aurel32.net/info/debian_arm_qemu.php.
>>
>>  It's working fine (about 1 minute to boot in my PC).
>>
>>  regards,
>>
>>  Màrius
>>
>>  PianoPan wrote:
>>
>> Hello, everyone,
>>
>>
>>
>> Now, I'm planning to use Qemu as our mobile device emulator (ARM).
>> Before our development, I want to confirm performance of it. I use
>> packages from http://folks.o-hand.com/richard/qemu.html to build the
>> evaluation environment, but performance of Linux in Qemu is too slow.
>> It uses about one hour to boot GUI system.
>>
>>
>>
>> Can anybody tell me this performance is proper or not?
>>
>> Best regards! Piano Pan
>>    ________________________________
>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>
>>
>>
>> -- 
>>
>>        Màrius Montón i Macián    marius.monton@uab.cat        
>> http://cephis.uab.es
>>        Hardware Engineer
>>         CEPHIS
>>        Centre de Prototips i Solucions Hardware-Software
>>  Dep. Microelectrònica i Sistemes Electrònics
>>  ETSE - Universitat Autònoma de Barcelona (UAB)         Phone: +34
>> 935 813 534
>>         Fax: +34 935 813 033
>>         QC-2090D. ETSE. Campus UAB.
>>         080193 Bellaterra
>>
>> _______________________________________________
>> 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
>

-- 
Màrius Montón i Macián   marius.monton@uab.cat
<mailto:marius.monton@uab.cat>  http://cephis.uab.es
<http://www.mariusmonton.name>
Hardware Engineer
CEPHIS
Centre de Prototips i Solucions Hardware-Software
Dep. Microelectrònica i Sistemes Electrònics
ETSE - Universitat Autònoma de Barcelona (UAB) 	Phone: +34 935 813 534
Fax: +34 935 813 033
QC-2090D. ETSE. Campus UAB.
080193 Bellaterra



[-- Attachment #1.2: Type: text/html, Size: 5803 bytes --]

[-- Attachment #2: marius.monton.vcf --]
[-- Type: text/x-vcard, Size: 440 bytes --]

begin:vcard
fn;quoted-printable:M=C3=A0rius Mont=C3=B3n
n;quoted-printable;quoted-printable:Mont=C3=B3n;M=C3=A0rius
org;quoted-printable:CEPHIS;Microelectr=C3=B2nica i Sistemes Electronics
adr:Campus de la UAB;;QC-2090D, ETSE;Bellaterra;Barcelona;08193;Spain
email;internet:marius.monton@uab.es
title:HW Engineer
tel;work:+34935813534
tel;fax:+34935813033
x-mozilla-html:TRUE
url:http://cephis.uab.es
version:2.1
end:vcard

Re: [Qemu-devel] qemu-system-* using mmap?

[Paul Brook]

On Wednesday 13 December 2006 14:40, Tim Olson wrote:
> I am using qemu 0.8.2 built from source.  In the qemu technical
> documentation for features under full system emulation, it says:
>
> "QEMU can either use a full software MMU for maximum portability or use
> the host system call mmap() to simulate the target MMU."
>
> However, I cannot find a way to build a full system simulator which
> does not define SOFTMMU -- in fact, the configure parameters
> "--disable-system" and "--enable-system" directly control the softmmu
> switch.  There are some mmap() calls in the kqemu code, but to use that
> requires full kqemu support code in the kernel.

This is unrelated.

> I think there is a big performance hit using the software mmu, as each
> target load or store instruction is expanded into 20-30 host
> instructions to perform the translation.  Is there a way to build the
> qemu-system-* emulators using the mmap() feature mentioned in the
> documentation?

No. That feature was removed some time ago. It only worked with modified guest 
OS. Once you start doing that you generally may as well use UML or Xen.
It's actually more like 10 instructions to do the translation.

Paul

Re: [Qemu-devel] qemu-system-* using mmap?

[Joseph Miller]

Tim Olson wrote:
> I am using qemu 0.8.2 built from source.  In the qemu technical 
> documentation for features under full system emulation, it says:
>
> "QEMU can either use a full software MMU for maximum portability or 
> use the host system call mmap() to simulate the target MMU."
>
> However, I cannot find a way to build a full system simulator which 
> does not define SOFTMMU -- in fact, the configure parameters 
> "--disable-system" and "--enable-system" directly control the softmmu 
> switch.  There are some mmap() calls in the kqemu code, but to use 
> that requires full kqemu support code in the kernel.
>
> I think there is a big performance hit using the software mmu, as each 
> target load or store instruction is expanded into 20-30 host 
> instructions to perform the translation.  Is there a way to build the 
> qemu-system-* emulators using the mmap() feature mentioned in the 
> documentation?
>
>     -- Tim Olson
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Can someone elaborate on this a little?  What is the difference between 
the SOFTMMU and the mmap()?  Should I be using the --enable-system or 
the --disable-system for win32 guest on i386 debian host?  Can someone 
give a little more insight on this technicality?

-Joseph

Re: [Qemu-devel] qemu-system-* using mmap?

[Tim Olson]

On Dec 13, 2006, at 10:04 AM, Joseph Miller wrote:

>
> Can someone elaborate on this a little?  What is the difference 
> between the SOFTMMU and the mmap()?  Should I be using the 
> --enable-system or the --disable-system for win32 guest on i386 debian 
> host?  Can someone give a little more insight on this technicality?

For full system emulation, qemu needs to support the emulated 
processor's ability to perform virtual->physical address translation 
for every memory reference (including data loads/stores and 
non-pc-relative branches).  Using the SOFTMMU method, this is done at 
basic-block translation time by inlining a software TLB lookup routine 
for each memory reference.  This expands a simple target load 
instruction into a sequence of ~20 host processor instructions (for x86 
target, ppc host I see about 25 instructions for TLB lookup).

The other way to handle this would be to use the host's MMU to do the 
translation directly, via an mmap() system call which sets up the 
translation.  Then the translated basic block would contain memory 
references using the target system's virtual address values, and the 
translation would occur in the host's hardware MMU during execution 
(fast), rather than having to execute a software TLB lookup.  However, 
there are a number of restrictions to using mmap() translation (host 
and target address spaces cannot overlap, etc.)  It appears that this 
feature has been removed from current versions of qemu, so the only way 
to do full system emulation is via the SOFTMMU method.

	-- tim

Re: [Qemu-devel] using mmap?

[Paul Brook]

> Does anyone know the reason for the removal of the mmap()? I have used 
> a benchmarking tool (I think it was 3D Mark05 or 3D Mark06) and the
> memory access in the guest WinXP was slooooooow.  Does anyone have any
> insight on making the hardware MMU function for linux-x86 host to WinXP
> 32-bit guest, even partially? 

As I already said, the code required a modified guest OS. i.e. it wouldn't 
work with windows guests anyway.

It was removed because it provided very little benefit, and wasn't worth the 
effort to keep it working.  Its uses were very specialised, and IMHO better 
covered by other products like UML or xen.

I'm also doubtful how much benefit it gave in practice. I'm sure it would be 
good for synthetic CPU benchmarks. However using mmap significantly increases 
the overhead of context switches/tlb misses.

To get good overall performance I suspect you're going to need closer 
cooperation with the kernel than mmap gives you. If you really want to make 
cross-emulation go fast I suggest working with the xen and/or kvm people to 
integrate qemu dynamic translation into those products. In theory I'd guess 
you should be able to plug it in as an alternative to the HVM code. I've no 
idea how close that is to being practical.

> Wouldn't this be a *significant* 
> performance enhancement for this setup which I'm sure is a common one?
> Maybe this can be implemented for regular processes on the guest and
> only use the softmmu for the kernel?  Would someone point me in the
> right direction for technical information?  I have had to switch to
> vmware free player until Qemu+KQEMU reaches a point of similar
> performance, but I would really rather see Qemu advance further.

If you're using an accelerator (eg. kqemu or kvm) this is all irelevant as 
most code isn't run by qemu, it's virtualized by the accelerator. qemu just 
does the IO emulation.

Paul

Re: [Qemu-devel] using mmap?

[Joseph Miller]

Tim Olson wrote:
>
> On Dec 13, 2006, at 10:04 AM, Joseph Miller wrote:
>
>>
>> Can someone elaborate on this a little?  What is the difference 
>> between the SOFTMMU and the mmap()?  Should I be using the 
>> --enable-system or the --disable-system for win32 guest on i386 
>> debian host?  Can someone give a little more insight on this 
>> technicality?
>
> For full system emulation, qemu needs to support the emulated 
> processor's ability to perform virtual->physical address translation 
> for every memory reference (including data loads/stores and 
> non-pc-relative branches).  Using the SOFTMMU method, this is done at 
> basic-block translation time by inlining a software TLB lookup routine 
> for each memory reference.  This expands a simple target load 
> instruction into a sequence of ~20 host processor instructions (for 
> x86 target, ppc host I see about 25 instructions for TLB lookup).
>
> The other way to handle this would be to use the host's MMU to do the 
> translation directly, via an mmap() system call which sets up the 
> translation.  Then the translated basic block would contain memory 
> references using the target system's virtual address values, and the 
> translation would occur in the host's hardware MMU during execution 
> (fast), rather than having to execute a software TLB lookup.  However, 
> there are a number of restrictions to using mmap() translation (host 
> and target address spaces cannot overlap, etc.)  It appears that this 
> feature has been removed from current versions of qemu, so the only 
> way to do full system emulation is via the SOFTMMU method.
>
>     -- tim
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


Does anyone know the reason for the removal of the mmap()?  I have used 
a benchmarking tool (I think it was 3D Mark05 or 3D Mark06) and the 
memory access in the guest WinXP was slooooooow.  Does anyone have any 
insight on making the hardware MMU function for linux-x86 host to WinXP 
32-bit guest, even partially?  Wouldn't this be a *significant* 
performance enhancement for this setup which I'm sure is a common one?  
Maybe this can be implemented for regular processes on the guest and 
only use the softmmu for the kernel?  Would someone point me in the 
right direction for technical information?  I have had to switch to 
vmware free player until Qemu+KQEMU reaches a point of similar 
performance, but I would really rather see Qemu advance further.

-Joseph

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Paul Brook]

> > If you're using an accelerator (eg. kqemu or kvm) this is all irelevant
> > as most code isn't run by qemu, it's virtualized by the accelerator. qemu
> > just does the IO emulation.
> >
> > Paul
>
> OK, so mmap is not the way to increase some speed.  What needs to be
> done to provide a higher Qemu+KQEMU performance, comparable to
> VMPlayer?  How does VMPlayer manage to be so much faster than Qemu?  Is
> this simply an I/O bottleneck?  How would I go about finding out what
> the differences are and how we can improve Qemu+KQEMU performance?

A copy of the kqemu source would be a good start.

Paul

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Joseph Miller]

Paul Brook wrote:
>> Does anyone know the reason for the removal of the mmap()? I have used 
>> a benchmarking tool (I think it was 3D Mark05 or 3D Mark06) and the
>> memory access in the guest WinXP was slooooooow.  Does anyone have any
>> insight on making the hardware MMU function for linux-x86 host to WinXP
>> 32-bit guest, even partially? 
>>     
>
> As I already said, the code required a modified guest OS. i.e. it wouldn't 
> work with windows guests anyway.
>
> It was removed because it provided very little benefit, and wasn't worth the 
> effort to keep it working.  Its uses were very specialised, and IMHO better 
> covered by other products like UML or xen.
>
> I'm also doubtful how much benefit it gave in practice. I'm sure it would be 
> good for synthetic CPU benchmarks. However using mmap significantly increases 
> the overhead of context switches/tlb misses.
>
> To get good overall performance I suspect you're going to need closer 
> cooperation with the kernel than mmap gives you. If you really want to make 
> cross-emulation go fast I suggest working with the xen and/or kvm people to 
> integrate qemu dynamic translation into those products. In theory I'd guess 
> you should be able to plug it in as an alternative to the HVM code. I've no 
> idea how close that is to being practical.
>
>   
>> Wouldn't this be a *significant* 
>> performance enhancement for this setup which I'm sure is a common one?
>> Maybe this can be implemented for regular processes on the guest and
>> only use the softmmu for the kernel?  Would someone point me in the
>> right direction for technical information?  I have had to switch to
>> vmware free player until Qemu+KQEMU reaches a point of similar
>> performance, but I would really rather see Qemu advance further.
>>     
>
> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant as 
> most code isn't run by qemu, it's virtualized by the accelerator. qemu just 
> does the IO emulation.
>
> Paul
>   
OK, so mmap is not the way to increase some speed.  What needs to be 
done to provide a higher Qemu+KQEMU performance, comparable to 
VMPlayer?  How does VMPlayer manage to be so much faster than Qemu?  Is 
this simply an I/O bottleneck?  How would I go about finding out what 
the differences are and how we can improve Qemu+KQEMU performance?

-Joseph

Re: [Qemu-devel] using mmap?

[Mark Williamson]

> I'm also doubtful how much benefit it gave in practice. I'm sure it would
> be good for synthetic CPU benchmarks. However using mmap significantly
> increases the overhead of context switches/tlb misses.
>
> To get good overall performance I suspect you're going to need closer
> cooperation with the kernel than mmap gives you. If you really want to make
> cross-emulation go fast I suggest working with the xen and/or kvm people to
> integrate qemu dynamic translation into those products. In theory I'd guess
> you should be able to plug it in as an alternative to the HVM code. I've no
> idea how close that is to being practical.

http://wiki.xensource.com/xenwiki/HVM/V2E

The v2e stuff allows execution state to be extracted from the real CPU, 
plugged into QEmu for a bit for emulation, then transferred back to the real 
CPU again.  This is initially to be used for supporting Big Real Mode 
emulation on HVM platforms.  Later on it's planned to be used to accelerate 
IO emulation further.

Eventually this may provide a means to use QEmu's translator to execute kernel 
code whilst running user mode code under Xen.  It may be that this isn't as 
fast as other approaches, but it'd be a useful feature for Xen to have IMO.

Cheers,
Mark

> > Wouldn't this be a *significant*
> > performance enhancement for this setup which I'm sure is a common one?
> > Maybe this can be implemented for regular processes on the guest and
> > only use the softmmu for the kernel?  Would someone point me in the
> > right direction for technical information?  I have had to switch to
> > vmware free player until Qemu+KQEMU reaches a point of similar
> > performance, but I would really rather see Qemu advance further.
>
> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant as
> most code isn't run by qemu, it's virtualized by the accelerator. qemu just
> does the IO emulation.
>
> Paul
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

[Qemu-devel] Re: using mmap?

[Anthony Liguori]

Mark Williamson wrote:
>> I'm also doubtful how much benefit it gave in practice. I'm sure it would
>> be good for synthetic CPU benchmarks. However using mmap significantly
>> increases the overhead of context switches/tlb misses.
>>
>> To get good overall performance I suspect you're going to need closer
>> cooperation with the kernel than mmap gives you. If you really want to make
>> cross-emulation go fast I suggest working with the xen and/or kvm people to
>> integrate qemu dynamic translation into those products. In theory I'd guess
>> you should be able to plug it in as an alternative to the HVM code. I've no
>> idea how close that is to being practical.
> 
> http://wiki.xensource.com/xenwiki/HVM/V2E
> 
> The v2e stuff allows execution state to be extracted from the real CPU, 
> plugged into QEmu for a bit for emulation, then transferred back to the real 
> CPU again.  This is initially to be used for supporting Big Real Mode 
> emulation on HVM platforms.  Later on it's planned to be used to accelerate 
> IO emulation further.
> 
> Eventually this may provide a means to use QEmu's translator to execute kernel 
> code whilst running user mode code under Xen.  It may be that this isn't as 
> fast as other approaches, but it'd be a useful feature for Xen to have IMO.

I'd absolute like to get there.  The current Xen HVM code is a bit of a 
mess at the moment.  There are far too many assumptions about having 
VT/SVM hardware present.  However, I'd really like to get to a point 
where Xen could run unmodified guests on non VT/SVM hardware using qemu 
with user virtualization.

KVM is having similar trouble ATM with big real mode.  It would be very 
nice to also add a V2E like interface to KVM.

I'd also like to see the translator even used for paravirtual guests. 
This way we could still have a proper boot loader run without having to 
deal with paravirtualizing it.  It would be nice to use emulation to 
avoid paravirtualizing the non-performance critical bits.

Regards,

Anthony Liguori

> Cheers,
> Mark
> 
>>> Wouldn't this be a *significant*
>>> performance enhancement for this setup which I'm sure is a common one?
>>> Maybe this can be implemented for regular processes on the guest and
>>> only use the softmmu for the kernel?  Would someone point me in the
>>> right direction for technical information?  I have had to switch to
>>> vmware free player until Qemu+KQEMU reaches a point of similar
>>> performance, but I would really rather see Qemu advance further.
>> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant as
>> most code isn't run by qemu, it's virtualized by the accelerator. qemu just
>> does the IO emulation.
>>
>> Paul
>>
>>
>> _______________________________________________
>> Qemu-devel mailing list
>> Qemu-devel@nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Lonnie Mendez]

On Fri, 2006-12-15 at 17:20 -0500, Joseph Miller wrote:  
> I've got a copy of today's CVS, I was just assuming, since this is the 
> qemu-devel mailing list, that someone on the list who regularly works on 
> the qemu code would probably know more about this than I do.  I have 
> some assembly background, and I'm not afraid to start digging into x86 
> cpu internals, but I would like a starting point.  I'm really trying to 
> figure out something specific about qemu.  When running Qemu+KQEMU for 
> linux-x86 host on WinXP x86 guest, top shows that 70% or more of my cpu 
> is being use in the system portion.  When using vmplayer (free), top 
> shows less than 5% of my cpu in the system portion.  vmplayer seems to 
> be a LOT faster than Qemu, however I would prefer to use Qemu.  I have a 
> P4 2.6GHz host system with 1.5G RAM and 512MB RAM allocated to my guest 
> OS's.  Does anyone know the reason behind the slowdown?  Is anyone 
> familiar with what Qemu is so busy doing whilst sitting idle?  I should 
> note that I have compiled the KQemu into my 2.6 kernel instead of 
> loading it as a module.  I have found better performance with it this 
> way.  Any insight from a developer would be most appreciated.

Are you using the -kernel-kqemu switch?  I see idle usage of 6-10% with
kqemu using -kernel-kqemu on windows xp guest.  kqemu is closed source
software.  If you want a starting point for improving the acceleration
portion then start by improving qvm86 (the GPL'ed accelerator).

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Paul Brook]

On Friday 15 December 2006 22:20, Joseph Miller wrote:
> Paul Brook wrote:
> >>> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant
> >>> as most code isn't run by qemu, it's virtualized by the accelerator.
> >>> qemu just does the IO emulation.
> >>>
> >>> Paul
> >>
> >> OK, so mmap is not the way to increase some speed.  What needs to be
> >> done to provide a higher Qemu+KQEMU performance, comparable to
> >> VMPlayer?  How does VMPlayer manage to be so much faster than Qemu?  Is
> >> this simply an I/O bottleneck?  How would I go about finding out what
> >> the differences are and how we can improve Qemu+KQEMU performance?
> >
> > A copy of the kqemu source would be a good start.
>
> I've got a copy of today's CVS, 

You missed my point entirely. kqemu is a closed source module, there's 
absolutely nothing we can do with it.

Paul

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Christian MICHON]

On 12/15/06, Paul Brook <paul@codesourcery.com> wrote:
> > I've got a copy of today's CVS,
>
> You missed my point entirely. kqemu is a closed source module, there's
> absolutely nothing we can do with it.
>

well, we can use kqemu at least, right? :)

interesting benchmark: I started removing most of the graphics code
(which I originally believed was slowing down qemu a lot) and started
running through ssh on windows host + tap-win32 patch.

Using kqemu, I see no improvement in calculations, meaning the
graphical part (sdl) is not the main blocking point. Next on my
list of trials is the disk/io (we did some pthread experiment in the
past, I think we can get some more bandwith here).

one last point: last time I used qvm86 for windows host, it did
not give good results. Hanged OS, several reboots, qemu
hanging forever. And back then I was using up to date qvm86
cvs. Is qvm86 still active ? If yes (for windows host), I'll try to
do newer benchmarks.

-- 
Christian

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Lonnie Mendez]

On Fri, 2006-12-15 at 22:48 +0100, Christian MICHON wrote:
> Using kqemu, I see no improvement in calculations, meaning the
> graphical part (sdl) is not the main blocking point. Next on my
> list of trials is the disk/io (we did some pthread experiment in the
> past, I think we can get some more bandwith here).

   Disk I/O on Linux and Freebsd hosts should be improved as qemu uses
AIO.  The Windows build has stubs for the async routines.

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Paul Brook]

On Friday 15 December 2006 21:48, Christian MICHON wrote:
> On 12/15/06, Paul Brook <paul@codesourcery.com> wrote:
> > > I've got a copy of today's CVS,
> >
> > You missed my point entirely. kqemu is a closed source module, there's
> > absolutely nothing we can do with it.
>
> well, we can use kqemu at least, right? :)

QEMU is an open source project (and this list is hosted on a site that is 
explicitly for open source projects)· Thus any solution that involves 
proprietary closed source modules is offtopic.

Paul

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Joseph Miller]

Paul Brook wrote:
>>> If you're using an accelerator (eg. kqemu or kvm) this is all irelevant
>>> as most code isn't run by qemu, it's virtualized by the accelerator. qemu
>>> just does the IO emulation.
>>>
>>> Paul
>>>       
>> OK, so mmap is not the way to increase some speed.  What needs to be
>> done to provide a higher Qemu+KQEMU performance, comparable to
>> VMPlayer?  How does VMPlayer manage to be so much faster than Qemu?  Is
>> this simply an I/O bottleneck?  How would I go about finding out what
>> the differences are and how we can improve Qemu+KQEMU performance?
>>     
>
> A copy of the kqemu source would be a good start.
>
> Paul
>   
I've got a copy of today's CVS, I was just assuming, since this is the 
qemu-devel mailing list, that someone on the list who regularly works on 
the qemu code would probably know more about this than I do.  I have 
some assembly background, and I'm not afraid to start digging into x86 
cpu internals, but I would like a starting point.  I'm really trying to 
figure out something specific about qemu.  When running Qemu+KQEMU for 
linux-x86 host on WinXP x86 guest, top shows that 70% or more of my cpu 
is being use in the system portion.  When using vmplayer (free), top 
shows less than 5% of my cpu in the system portion.  vmplayer seems to 
be a LOT faster than Qemu, however I would prefer to use Qemu.  I have a 
P4 2.6GHz host system with 1.5G RAM and 512MB RAM allocated to my guest 
OS's.  Does anyone know the reason behind the slowdown?  Is anyone 
familiar with what Qemu is so busy doing whilst sitting idle?  I should 
note that I have compiled the KQemu into my 2.6 kernel instead of 
loading it as a module.  I have found better performance with it this 
way.  Any insight from a developer would be most appreciated.

-Joseph

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Christian MICHON]

On 12/15/06, Paul Brook <paul@codesourcery.com> wrote:
> QEMU is an open source project (and this list is hosted on a site that is
> explicitly for open source projects)· Thus any solution that involves
> proprietary closed source modules is offtopic.
>

ok, politically incorrect. point taken :)

yet, what about the second part of my reply ?

Is qvm86 still active ? if yes, great. if no, what do you need to restart it ?
(else than dedicated developpers, of course). As far as I can see, no
qvm86 check-in for 15 months now...

-- 
Christian

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Paul Brook]

> Is qvm86 still active ? if yes, great. if no, what do you need to restart
> it ? (else than dedicated developpers, of course). As far as I can see, no
> qvm86 check-in for 15 months now...

Not really. I haven't had chance to do anything with it for a while, and 
probably won't in the forseeable future. It probably wouldn't take more than 
a couple of weeks work for an experienced coder to get it working properly.

If someone else shows serious interest in qvm86 I've no real objection to 
handing over management of the project to them.

As Anthony mentioned, efforts might be best spent integrating this 
functionality into Xen or KVM. You're more than welcome to use qvm86 code for 
this.

Paul

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Jamie Lokier]

Paul Brook wrote:
> > OK, so mmap is not the way to increase some speed.  What needs to be
> > done to provide a higher Qemu+KQEMU performance, comparable to
> > VMPlayer?  How does VMPlayer manage to be so much faster than Qemu?  Is
> > this simply an I/O bottleneck?  How would I go about finding out what
> > the differences are and how we can improve Qemu+KQEMU performance?
> 
> A copy of the kqemu source would be a good start.

As would reading VMware peoples' publications on the tricks they've
used.  I'm thinking of a paper which compares VMware's performance on
hardware VM (newer Intel/AMD) versus software VM, and finds software
is actually faster in many cases.  It happens to mention in passing a
lot of tricks used by VMware.

-- Jamie

Re: [Qemu-devel] Qemu speed vs vmplayer?

[it]

> On Sat, 16 Dec 2006, it@tidetamerboatlifts.com wrote:
>
>>> On Fri, 15 Dec 2006, Joseph Miller wrote:
>
> [..snip..]
>
>> Malc,
>>
>> Thanks,
>> I think that this was my problem.  I didn't realize that the usb tablet
>> would cause such a slowdown.  The usb tablet is such a useful feature,
>> I'm
>> sure it is commonly used.  Maybe a warning could be provided so that
>> users
>> would know it has some performance quirks.  Maybe I can look at the code
>> and find out why it is so much slower?  Maybe this is a general usb
>> problem?
>
> You think? As in: tried with and without USB and top reports much higher
> CPU usage? In any case do not rely on top(1) too much, as mentioned in
> the post for certain CPU usage patterns Linux just does not provide a
> meaningful idleness information (which top uses).
>
> Again as mentioned in the post, i have seen 30%-40% difference between
> "real" idleness and what the kernel reports via proc, but 70% is a bit
> too much. The negative impact of USB (tablet only?) on the load was
> mentioned a few times on the ML and in private conversations with
> Anthony Liguori and since there was no progress in this area i doubt
> that there's much you can do apart from reporting the issue once again.
>
> Apparently you wont find much symphaty when reporting the speed issues
> while kqemu is active. So i'd suggest to:
>
>   a. Measure and report the difference without kqemu
>   b. Use something more reliable than top(1)
>
> --
> vale
>

Yeah, I said "I think" because I wanted to use a decent benchmark to
actually test the results.  I threw in a test against VMPlayer as well.  I
found that with USB tablet emulation, Qemu was approximately only half as
fast as it could operate without it.  I did NOT perform these tests
without KQEMU for two reasons 1) the *concept* that USB tablet emulation
slows down Qemu can be shown either way and 2) I can't stand waiting
around for hours and hours while Qemu translates code, sorry.  At this
particular time, I'm really only interested in this particular case
because I use it for production use and many non-developer users are
wanting to do the same thing.  The only major difference that I found
between Qemu+KQEMU and VMPlayer was that VMPlayer is about 4x faster when
it comes to memory access.  You can view my results at:

http://www.calcmaster.net/qemu/benchmarks-20061216/

-Joseph

Re: [Qemu-devel] Qemu speed vs vmplayer?

[Lonnie Mendez]

On Sat, 2006-12-16 at 23:37 -0500, it@tidetamerboatlifts.com wrote:
> Yeah, I said "I think" because I wanted to use a decent benchmark to
> actually test the results.  I threw in a test against VMPlayer as well.  I
> found that with USB tablet emulation, Qemu was approximately only half as
> fast as it could operate without it.  I did NOT perform these tests
> without KQEMU for two reasons 1) the *concept* that USB tablet emulation
> slows down Qemu can be shown either way and 2) I can't stand waiting
> around for hours and hours while Qemu translates code, sorry.  At this
> particular time, I'm really only interested in this particular case
> because I use it for production use and many non-developer users are
> wanting to do the same thing.  The only major difference that I found
> between Qemu+KQEMU and VMPlayer was that VMPlayer is about 4x faster when
> it comes to memory access.  You can view my results at:
> 
> http://www.calcmaster.net/qemu/benchmarks-20061216/

Two things:

1.  http://www.vmware.com/download/eula/player.html
    (Restrictions - Section 3.3 - "You may use the Software to ...")

2.  http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00360.html

Re: [Qemu-devel] Qemu speed w/ USB tablet emulation

[Joseph Miller]

Lonnie Mendez wrote:
> On Sat, 2006-12-16 at 23:37 -0500, it@tidetamerboatlifts.com wrote:
>   
>> Yeah, I said "I think" because I wanted to use a decent benchmark to
>> actually test the results.  I threw in a test against VMPlayer as well.  I
>> found that with USB tablet emulation, Qemu was approximately only half as
>> fast as it could operate without it.  I did NOT perform these tests
>> without KQEMU for two reasons 1) the *concept* that USB tablet emulation
>> slows down Qemu can be shown either way and 2) I can't stand waiting
>> around for hours and hours while Qemu translates code, sorry.  At this
>> particular time, I'm really only interested in this particular case
>> because I use it for production use and many non-developer users are
>> wanting to do the same thing.  The only major difference that I found
>> between Qemu+KQEMU and VMPlayer was that VMPlayer is about 4x faster when
>> it comes to memory access.  You can view my results at:
>>
>> http://www.calcmaster.net/qemu/benchmarks-20061216/
>>     
>
> Two things:
>
> 1.  http://www.vmware.com/download/eula/player.html
>     (Restrictions - Section 3.3 - "You may use the Software to ...")
>
> 2.  http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00360.html
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>   
I have tested and benchmarked this USB tablet emulation patch from 
http://lists.gnu.org/archive/html/qemu-devel/2006-07/msg00360.html on my 
website at  http://www.calcmaster.net/qemu/benchmarks-20061216/ and you 
can see that this patch makes a HUGE difference in performance.  Is 
there any way that this patch could be committed any time soon?

-Joseph

P.S. Any insight on why Qemu's memory access is so much slower than a 
vmplayer?  Fabrice?