Re: [Qemu-discuss] USE QEMU + KVM TO RUN CUSTOM KERNEL

[Jakob Bohm]

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 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded