From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4peg-0005zI-Kr for qemu-devel@nongnu.org; Thu, 22 Apr 2010 02:12:54 -0400 Received: from [140.186.70.92] (port=47359 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4pee-0005yi-Ke for qemu-devel@nongnu.org; Thu, 22 Apr 2010 02:12:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4pec-0002XN-1k for qemu-devel@nongnu.org; Thu, 22 Apr 2010 02:12:52 -0400 Received: from chello084112167138.7.11.vie.surfer.at ([84.112.167.138]:50001 helo=wiesinger.com) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4peb-0002X9-JY for qemu-devel@nongnu.org; Thu, 22 Apr 2010 02:12:50 -0400 Date: Thu, 22 Apr 2010 08:12:23 +0200 (CEST) From: Gerhard Wiesinger Subject: Re: [Qemu-devel] Re: QEMU-KVM and video performance In-Reply-To: <20100421213010.GC27575@shareable.org> 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 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org 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/