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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
