[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: Another SIGFPE in display code, now in cirrus
From: |
Stefano Stabellini |
Subject: |
[Qemu-devel] Re: Another SIGFPE in display code, now in cirrus |
Date: |
Wed, 12 May 2010 13:20:02 +0100 |
User-agent: |
Alpine 2.00 (DEB 1167 2008-08-23) |
On Mon, 10 May 2010, Avi Kivity wrote:
> 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.
>
Reading some documention about the Cirrus card we are emulating, it
seems that the source pitch is ignored in video to video operations, so
I think you are right here.
The Windows NT driver probably relies on this behaviour and doesn't set
the source pitch properly before the bitblt.
> 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.
>
I agree with you: qemu_console_copy does imply that the copied portion
of the screen changed, so there is no reason to invalidate it again if
qemu_console_copy is called.
- [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Avi Kivity, 2010/05/10
- [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Avi Kivity, 2010/05/10
- [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus,
Stefano Stabellini <=
- [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Avi Kivity, 2010/05/12
- [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Stefano Stabellini, 2010/05/12
- [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Avi Kivity, 2010/05/12
- [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Stefano Stabellini, 2010/05/12
- [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Avi Kivity, 2010/05/12
- [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Stefano Stabellini, 2010/05/12
- [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Avi Kivity, 2010/05/12
- Re: [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Jamie Lokier, 2010/05/12
- Re: [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Stefano Stabellini, 2010/05/12
- Re: [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus, Michael Tokarev, 2010/05/12