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/
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
