From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48793 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OC96K-0004az-KG for qemu-devel@nongnu.org; Wed, 12 May 2010 06:23:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OC96F-0006eQ-Tj for qemu-devel@nongnu.org; Wed, 12 May 2010 06:23:39 -0400 Received: from mail2.shareable.org ([80.68.89.115]:45827) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OC96F-0006e1-Oe for qemu-devel@nongnu.org; Wed, 12 May 2010 06:23:35 -0400 Date: Wed, 12 May 2010 11:23:20 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: QEMU-KVM and video performance Message-ID: <20100512102320.GC16879@shareable.org> 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 Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerhard Wiesinger Cc: Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org Gerhard Wiesinger wrote: > 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)? Yes it is a general problem, but KVM emulates some time-critical things in the kernel (like APIC and CPU instructions), so it's not too bad. KVM is about 5x faster than TCG for most things, and slower for a few things, so on balance it is usually faster. The slow 256-colour mode writes sound like just a simple bug, though. No need for complicated changes. > >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.) > > > >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? Look up Mode X on Wikipedia if you're interested, but it isn't relevant to the problem you've reported. Mode X cannot be enabled with a BIOS call; it's a VGA hardware programming trick. It would not be useful in a VM environment. -- Jamie