Hello,
Some update on this issue, archive: http://www.mail-archive.com/kvm@vger.kernel.org/msg32600.html
Seems to be that cirrus VGA is now ok (>1000MB/s up to 2000MB/s). But cirrus has only 320x200x256colors (Mode 13h) mode implemented in VESA BIOS.
VMWare and std VGA still have the performance issue.
I guess improvement is related to the following commit: http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=commitdiff;h=0d14905b5eb8aa... Especially i guess the change in hw/cirrus_vga.c.
Any idea how to fix: 1.) More VESA modes in cirrus VGA (is VESA emulation done by Seabios or by KVM cirrus BIOS?) 2.) fix in VMWare and std VGA modes the performance, too
Versions are latest dev versions of KVM user part and Seabios from GIT.
Thnx.
Ciao, Gerhard
On Wed, 12 May 2010, Avi Kivity wrote:
On 05/12/2010 09:14 AM, Gerhard Wiesinger wrote:
On Mon, 10 May 2010, Avi Kivity wrote:
On 05/09/2010 10:35 PM, Gerhard Wiesinger wrote:
For 256 color more the first priority is to find out why direct mapping is not used. I'd suggest tracing the code that makes this decision (in hw/*vga.c) and seeing if it's right or not.
I think this is because A000 is not initialized for KVM (see log below and logging patch attached).
Why isn't it initialized?
Did the guest configure things such as it is impossible to map it directly? Or does the configuration allow direct mapping and qemu incorrectly decides that it cannot direct map?
Best would be to print out all the configuration registers and interpret them according to the specification.
vga_dirty_log_start vga_dirty_log_start_mapping_lfb_vram_mapped, start=0x000A0000, len=0x00008000 BUG: kvm_dirty_pages_log_change: invalid parameters 00000000000a0000-00000000000a7fff
Why does this happen?
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
-
Gerhard Wiesinger