From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerhard Wiesinger Subject: Re: [Qemu-devel] Re: QEMU-KVM and video performance Date: Thu, 22 Apr 2010 08:12:23 +0200 (CEST) Message-ID: References: <4BCEBE5C.4020404@redhat.com> <20100421183357.GK27575@shareable.org> <20100421185322.GN27575@shareable.org> <20100421213010.GC27575@shareable.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Avi Kivity , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Jamie Lokier Return-path: Received: from chello084112167138.7.11.vie.surfer.at ([84.112.167.138]:50007 "EHLO wiesinger.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751949Ab0DVGNI (ORCPT ); Thu, 22 Apr 2010 02:13:08 -0400 In-Reply-To: <20100421213010.GC27575@shareable.org> Sender: kvm-owner@vger.kernel.org List-ID: 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/