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
--
http://www.wiesinger.com/
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