From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4XmB-0006wV-Kv for qemu-devel@nongnu.org; Wed, 21 Apr 2010 07:07:27 -0400 Received: from [140.186.70.92] (port=46159 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4Xm3-00040U-7w for qemu-devel@nongnu.org; Wed, 21 Apr 2010 07:07:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4XUd-0004Ag-Ns for qemu-devel@nongnu.org; Wed, 21 Apr 2010 06:49:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17403) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4XUd-0004AW-Fr for qemu-devel@nongnu.org; Wed, 21 Apr 2010 06:49:19 -0400 Message-ID: <4BCED82C.9020702@redhat.com> Date: Wed, 21 Apr 2010 13:49:16 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: QEMU-KVM and video performance References: <4BCEBE5C.4020404@redhat.com> <20100421100840.GF13114@shareable.org> In-Reply-To: <20100421100840.GF13114@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Gerhard Wiesinger , qemu-devel@nongnu.org, kvm@vger.kernel.org On 04/21/2010 01:08 PM, Jamie Lokier wrote: > Avi Kivity wrote: > >> On 04/19/2010 10:14 PM, Gerhard Wiesinger wrote: >> >>> Hello, >>> >>> Finally I got QEMU-KVM to work but video performance under DOS is very >>> low (QEMU 0.12.3 stable and QEMU GIT master branch is fast, QEMU KVM >>> is slow) >>> >>> I'm measuring 2 performance critical video performance parameters: >>> 1.) INT 10h, function AX=4F05h (set same window/set window/get window) >>> 2.) Memory performance to segment page A000h >>> >>> So BIOS performance (which might be port performance to VGA >>> index/value port) is about factor 5 slower, memory performance is >>> about factor 100 slower. >>> >>> QEMU 0.12.3 and QEMU GIT performance is the same (in the measurement >>> tolerance) and listed only once, QEMU KVM is much more slower (details >>> see below). >>> >>> Test programs can be provided, source code will be release soon. >>> >>> Any ideas why KVM is so slow? >>> >> 16-color vga is slow because kvm cannot map the framebuffer to the guest >> (writes are not interpreted as RAM writes). 256+-color vga should be >> fast, except when switching the vga window. Note it's only fast on >> average, the first write into a page will be slow as kvm maps it in. >> > I don't understand: why is 256+-colour mappable and 16-colour not mappable? > Writes to vga in 16-color mode don't change set a memory location to a value, instead they change multiple memory locations. > Is this a case where TCG would run significantly faster for code blocks > that have been detected to access the VGA memory? > Yes. >> Currently when the physical memory map changes (which is what happens >> when the vga window is updated), kvm drops the entire shadow cache. >> It's possible to do this only for vga memory, but not easy. >> > If it's a page fault handled in the kernel, I would expect it to be > about as fast as those old VGA DOS-extender drivers which provide the > illusion of a single flat mapping, and bank switch on page faults - > multiplied by the speed of modern CPUs compared with then. For many > graphics things those DOS-extender drivers worked perfectly well. > > If it's a trap out to qemu on every vga window change, perhaps not > quite so well. > It's much more complicated. -- error compiling committee.c: too many arguments to function