[prev in list] [next in list] [prev in thread] [next in thread]
List: qemu-discuss
Subject: [Qemu-discuss] =?big5?b?pl7C0DogIFVTRSBRRU1VICsgS1ZNIFRPIFJVTiBD?= =?big5?b?VVNUT00gS0VSTkVM?=
From: <itriA30110 () itri ! org ! tw>
Date: 2016-05-05 7:40:33
Message-ID: 1462434032037.46481 () itri ! org ! tw
[Download RAW message or body]
[Attachment #2 (text/plain)]
What is your expecting performance?
Vga of stdvga and cirrus are all software renderer, and their IO addresses were all \
emulated by virtual memory (i.e. mmap). The doubled R/W access time seems be \
reasonable.
________________________________
從: Qemu-discuss <qemu-discuss-bounces+itria30110=itri.org.tw@nongnu.org> 代表 \
giuseppe maugeri <giumaug@gmail.com> 寄件日期: 2016年05月05日 04:47
至: qemu-discuss@nongnu.org
主旨: Re: [Qemu-discuss] USE QEMU + KVM TO RUN CUSTOM KERNEL
I tried to launch Qemu with Vga set to cirrus,std and vmware.
Same bad numbers.
Is my only option to patch Qemu + KVM?
I also noted some slowdown in my ata custom driver.
The driver currently supports pio mode only.
Is this mode optimized in Qemu and Qemu + KVM?
Regards,
Giuseppe.
2016-05-04 22:39 GMT+02:00 giuseppe maugeri \
<giumaug@gmail.com<mailto:giumaug@gmail.com>>: I tried to launch Qemu with Vga set to \
cirrus,std and vmware. Same bad numbers.
Is my only option to patch Qemu + KVM?
I also noted some slowdown in my ata custom driver.
The driver currently supports pio mode only.
Is this mode optimized in Qemu and Qemu + KVM?
Regards,
Giuseppe.
2016-05-04 11:23 GMT+02:00 Jakob Bohm \
<jb-gnumlists@wisemo.com<mailto:jb-gnumlists@wisemo.com>>: On 04/05/2016 10:50, \
giuseppe maugeri wrote: Hi,
i'm developing a custom kernel for x86 platform.So Far i used as virtual environment \
Simics. Recently i decided to move to Qemu.
Running my kernel on Qemu I found it tremendously slow even with KVM enabled.
Here a little example:
#include "lib/lib.h"
main()
{
int i=0;
for (i=0;i<=900000;i++)
{
printf("num=%d \n",i);
}
exit(0);
}
In this code printf uses a custom simple system call that switch the kernel in ring \
mode and writes a string in the text screen video memory at 0xB8000. Performace are \
awful in Qemu even with KVM support.
With Simics performance are very close to real hardware.
Some number:
Running code under Linux on real hardware 30 sescs
Running code under my os with qemu with no kvm 4 min
Running code under my os with qemu+kmv 60 minites.
This is my Qemu launch string with KVM:
./qemu-system-x86_64 -enable-kvm -m 1000M -hda /home/peppe/Scrivania/disk.img
KVM module is loaded:
lsmod | grep kvm
kvm_intel 142999 0
kvm 444314 1 kvm_intel
To double check my virtualization environment i loaded a Fedora 13 live image with \
Qemu + KVM and all is worked as expected.
MY Question is:
Why my code is so slow under KVM?
Need i to perform a special tuning on KVM?
Is KVM SUTED to run custom kernel like mine?
In this example i suppose KVM needs to perform some special trap in order to access \
to text memory video. Just because this is a unusual path is it perhaps not \
optimized?
Have you tried varying the options for the virtual video card?
Maybe the default video card does something like the
following (I am guessing):
qemu alone: Each write to the 128K block at A0000 is special
cased as a call to the video card emulator, which instantly
knows which character cell you wrote.
qemu+kvm: Each write to the 128K block at A0000 triggers a
page fault to the KVM driver which then uses a less efficient
single instruction stepper to execute the faulting
instruction (so the write actually goes through), then tells
qemu which 4K page was modified. Then qemu has to figure out
which bytes in those 4K were modified in order to figure out
which character cell(s) to need to be redrawn. Even on a fast
CPU this is not unlikely to consume the observed 25us per
character.
The above mechanisms are probably needed to emulate the
special memory write behavior of VGA 640x480 graphics mode,
and some similar modes, but are not the most efficient way
to emulate a text mode MDA/HGA/CGA/EGA/VGA simple VRAM
buffer if the final output device is a fast display and not
e.g. a tty-protocol "terminal" or a remote X/VNC server.
Choosing a different virtual video card might result in a
different algorithm for managing the A0000/128K block when
in classic text modes.
As for the Fedora image, I don't know if that uses a different
video mode where the qemu code is more optimized (because
Fedora/RedHat are big promoters of KVM and would have
optimized the default cases to work together).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. Direct +45 31 13 16 \
10<tel:%2B45%2031%2013%2016%2010> This public discussion message is non-binding and \
may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
====================================================================
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 \
This email may contain confidential information. Please do not use or disclose it in \
any way and delete it if you are not the intended recipient.
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<style type="text/css" style="display:none"><!--P{margin-top:0;margin-bottom:0;} \
--></style> </head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>What is your expecting performance?</p>
<p><br>
</p>
<p>Vga of stdvga and cirrus are all software renderer, and their IO \
addresses were all emulated by virtual memory (i.e. mmap). The doubled R/W \
access time seems be reasonable.</p> <p><br>
</p>
<div style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" \
face="Calibri, sans-serif"><b>從:</b> Qemu-discuss \
<qemu-discuss-bounces+itria30110=itri.org.tw@nongnu.org> 代表 giuseppe \
maugeri <giumaug@gmail.com><br> <b>寄件日期:</b> 2016年05月05日 04:47<br>
<b>至:</b> qemu-discuss@nongnu.org<br>
<b>主旨:</b> Re: [Qemu-discuss] USE QEMU + KVM TO RUN CUSTOM KERNEL</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>I tried to launch Qemu with Vga set to cirrus,std and vmware.<br>
</div>
<div>Same bad numbers.<br>
</div>
<div>Is my only option to patch Qemu + KVM?<br>
</div>
<div>I also noted some slowdown in my ata custom driver.<br>
</div>
<div>The driver currently supports pio mode only.<br>
</div>
<div>Is this mode optimized in Qemu and Qemu + KVM?<br>
<br>
</div>
<div>Regards,<br>
</div>
Giuseppe.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-05-04 22:39 GMT+02:00 giuseppe maugeri <span \
dir="ltr"> <<a href="mailto:giumaug@gmail.com" \
target="_blank">giumaug@gmail.com</a>></span>:<br> <blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex"> <div \
dir="ltr"> <div>I tried to launch Qemu with Vga set to cirrus,std and vmware.<br>
</div>
<div>Same bad numbers.<br>
</div>
<div>Is my only option to patch Qemu + KVM?<br>
</div>
<div>I also noted some slowdown in my ata custom driver.<br>
</div>
<div>The driver currently supports pio mode only.<br>
</div>
<div>Is this mode optimized in Qemu and Qemu + KVM?<br>
<br>
</div>
<div>Regards,<br>
</div>
<div>Giuseppe.<br>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-05-04 11:23 GMT+02:00 Jakob Bohm <span \
dir="ltr"><<a href="mailto:jb-gnumlists@wisemo.com" \
target="_blank">jb-gnumlists@wisemo.com</a>></span>:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; \
padding-left:1ex"> <div bgcolor="#FFFFFF">
<div>
<div>
<div>On 04/05/2016 10:50, giuseppe maugeri wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,<br>
i'm developing a custom kernel for x86 platform.So Far i used as virtual environment \
Simics.<br> Recently i decided to move to Qemu.<br>
Running my kernel on Qemu I found it tremendously slow even with KVM enabled.<br>
<br>
Here a little example:<br>
<br>
#include "lib/lib.h"<br>
<br>
main()<br>
{<br>
int i=0;<br>
for (i=0;i<=900000;i++) \
<br> {<br>
\
printf("num=%d \n",i);<br> \
}<br> exit(0);<br>
}<br>
<br>
In this code printf uses a custom simple system call that switch the kernel in ring \
mode and writes a string in the text screen video memory at 0xB8000.<br> Performace \
are awful in Qemu even with KVM support.<br> <br>
With Simics performance are very close to real hardware.<br>
<br>
Some number:<br>
Running code under Linux on real hardware 30 sescs<br>
Running code under my os with qemu with no kvm 4 min<br>
Running code under my os with qemu+kmv 60 minites.<br>
<br>
This is my Qemu launch string with KVM:<br>
./qemu-system-x86_64 -enable-kvm -m 1000M -hda /home/peppe/Scrivania/disk.img<br>
<br>
KVM module is loaded:<br>
lsmod | grep kvm<br>
kvm_intel 142999 0 <br>
kvm 444314 1 kvm_intel<br>
<br>
To double check my virtualization environment i loaded a Fedora 13 live image with \
Qemu + KVM and all is worked as expected.<br> <br>
MY Question is:<br>
Why my code is so slow under KVM?<br>
Need i to perform a special tuning on KVM?<br>
Is KVM SUTED to run custom kernel like mine?<br>
<br>
In this example i suppose KVM needs to perform some special trap in order to access \
to text memory video.<br> Just because this is a unusual path is it perhaps not \
optimized?<br> <br>
</div>
</blockquote>
</div>
</div>
<tt>Have you tried varying the options for the virtual video card?<br>
<br>
Maybe the default video card does something like the <br>
following (I am guessing):<br>
<br>
qemu alone: Each write to the 128K block at A0000 is special <br>
cased as a call to the video card emulator, which instantly <br>
knows which character cell you wrote.<br>
<br>
qemu+kvm: Each write to the 128K block at A0000 triggers a <br>
page fault to the KVM driver which then uses a less efficient <br>
single instruction stepper to execute the faulting <br>
instruction (so the write actually goes through), then tells <br>
qemu which 4K page was modified. Then qemu has to figure out <br>
which bytes in those 4K were modified in order to figure out <br>
which character cell(s) to need to be redrawn. Even on a fast <br>
CPU this is not unlikely to consume the observed 25us per <br>
character.<br>
<br>
The above mechanisms are probably needed to emulate the <br>
special memory write behavior of VGA 640x480 graphics mode, <br>
and some similar modes, but are not the most efficient way <br>
to emulate a text mode MDA/HGA/CGA/EGA/VGA simple VRAM <br>
buffer if the final output device is a fast display and not <br>
e.g. a tty-protocol "terminal" or a remote X/VNC server.<br>
<br>
Choosing a different virtual video card might result in a <br>
different algorithm for managing the A0000/128K block when <br>
in classic text modes.<br>
<br>
As for the Fedora image, I don't know if that uses a different <br>
video mode where the qemu code is more optimized (because <br>
Fedora/RedHat are big promoters of KVM and would have <br>
optimized the default cases to work together).<br>
</tt>
<p><br>
</p>
<br>
<pre cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a href="https://www.wisemo.com" \
target="_blank">https://www.wisemo.com</a><span><font color="#888888"> Transformervej \
29, 2860 Søborg, Denmark. Direct <a href="tel:%2B45%2031%2013%2016%2010" \
value="+4531131610" target="_blank">+45 31 13 16 10</a> This public \
discussion message is non-binding and may contain errors. WiseMo - Remote Service \
Management for PCs, Phones and Embedded </font></span></pre> </div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</body>
</html>本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 \
<br> This email may contain confidential information. Please do not use or disclose \
it in any way and delete it if you are not the intended recipient.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic