On 05/10/2010 10:41 AM, Avi Kivity wrote:
On 05/06/2010 11:07 PM, Michael Tokarev wrote:
There was a bug recently fixed in vnc code. Apparently
there's something similar in the cirrus emulation as well.
Here it triggers _always_ (including old versions of kvm)
when running windows NT and hitting "test" button in its
display resolution dialog. Here's what gdb is to say:
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0xf76cab70 (LWP 580)]
0x080c5e45 in cirrus_do_copy (s=0x86134dc, dst=960000, src=0, w=2, h=9)
at hw/cirrus_vga.c:687
687 sx = (src % ABS(s->cirrus_blt_srcpitch)) / depth;
(gdb) p depth
$1 = 2
(gdb) p s->cirrus_blt_srcpitch
$2 = 0
This qemu-kvm-0.12.3 - actually a debian package of it,
but there's no patches relevant to video applied.
Anything can be done with it?
Well, it's trivial to check for the condition, but how to handle it?
That code is wrong. It shouldn't be using the bitblt source pitch, but
the actual display pitch. If the two are different, then the blt
doesn't actually affect a rectangular region, but instead a parallelogram.
Further:
if (notify)
qemu_console_copy(s->vga.ds,
sx, sy, dx, dy,
s->cirrus_blt_width / depth,
s->cirrus_blt_height);
/* we don't have to notify the display that this portion has
changed since qemu_console_copy implies this */
cirrus_invalidate_region(s, s->cirrus_blt_dstaddr,
s->cirrus_blt_dstpitch, s->cirrus_blt_width,
s->cirrus_blt_height);
Shouldn't we avoid the invalidate if notify != 0, as the comment says?
31c05501c says this breaks bitblt, but I can't see why this is true.
The copy should update the display. This is probably due to a
miscalculation of the affected region, and now we have two invalidates
instead of one, reducing performance.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
