Re: [Qemu-devel] Re: QEMU-KVM and video performance

[Avi Kivity <avi@redhat.com>]

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