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. When QEMU does the same thing, it's fast because it's inside the same process; it's just a function call. 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 :-) 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. You might double-check if your guest is using VGA "Mode X". (See Wikipedia.) 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. -- Jamie -- 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
