From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerhard Wiesinger Subject: Re: Re: QEMU-KVM and video performance Date: Wed, 21 Apr 2010 20:14:15 +0200 (CEST) Message-ID: References: <4BCEBE5C.4020404@redhat.com> <20100421100840.GF13114@shareable.org> <4BCED82C.9020702@redhat.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org To: Avi Kivity Return-path: In-Reply-To: <4BCED82C.9020702@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On Wed, 21 Apr 2010, Avi Kivity wrote: > 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. > Can you explain which code files/functions of KVM is involved in handling VGA memory window and page switching through the port write to the VGA window register (or is that part handled through QEMU), so a little bit architecture explaination would be nice? BTW: In which KVM code parts is decided where "direct code" or an "emulated device code" is used? Thnx. Ciao, Gerhard -- http://www.wiesinger.com/