Re: [Qemu-devel] Re: QEMU-KVM and video performance

[Gerhard Wiesinger <lists@wiesinger.com>]

On Wed, 21 Apr 2010, Jamie Lokier wrote:

> Gerhard Wiesinger wrote:
>> Hmmm. I'm very new to QEMU and KVM but at least accessing the virtual HW
>> of QEMU even from KVM must be possible (e.g. memory and port accesses are
>> done on nearly every virtual device) and therefore I'm ending in C code in
>> the QEMU hw/*.c directory. Therefore also the VGA memory area should be
>> able to be accessable from KVM but with the specialized and fast memory
>> access of QEMU.  Am I missing something?
>
> What you're missing is that when KVM calls out to QEMU to handle
> hw/*.c traps, that call is very slow.  It's because the hardware-VM
> support is a bit slow when the trap happens, and then the the call
> from KVM in the kernel up to QEMU is a bit slow again.  Then all the
> way back.  It adds up to a lot, for every I/O operation.

Isn't that then a general problem of KVM virtualization (oder hardware 
virtualization) in general? Is this CPU dependend (AMD vs. Intel)?

> When QEMU does the same thing, it's fast because it's inside the same
> process; it's just a function call.

Yes, that's clear to me.

> That's why the most often called devices are emulated separately in
> KVM's kernel code, things like the interrupt controller, timer chip
> etc.  It's also why individual instructions that need help are
> emulated in KVM's kernel code, instead of passing control up to QEMU
> just for one instruction.

>> BTW: Still not clear why performance is low with KVM since there are
>> no window changes in the testcase involved which could cause a (slow) page
>> fault.
>
> It sounds like a bug.  Avi gave suggests about what to look for.
> If it fixes my OS install speeds too, I'll be very happy :-)
>

See other post for details.

> In 256-colour mode, KVM should be writing to the VGA memory at high
> speed a lot like normal RAM, not trapping at the hardware-VM level,
> and not calling up to the code in hw/*.c for every byte.
>


Yes, same picture to me: 256 color mode should be only a memory write (16 
color mode is more difficult as pixel/byte mapping is not the same).
But it looks like this isn't the case in this test scenario.

> You might double-check if your guest is using VGA "Mode X".  (See Wikipedia.)
>

Code:
 	inregs.x.ax = 0x4F02;
 	inregs.x.bx = 0xC000 | 0x101; // bh=bit 15=0 (clear), bit14=0 (windowed)
 	int86x(INT_SCREEN, &inregs, &outregs, &outsregs);		/* Call INT 10h */

I can post the whole code/exes if you want (I already planned to post my 
whole tools, but I have to do some cleanups until I wanted to publish 
whole package) .

> That was a way to accelerate VGA on real PCs, but it will be slow in
> KVM for the same reasons as 16-colour mode.

Which way do you mean?

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/