Re: Re: QEMU-KVM and video performance

[Gerhard Wiesinger <lists@wiesinger.com>]

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/