qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] Move graphic-related coalesced MMIO flushes


From: Alon Levy
Subject: Re: [Qemu-devel] [PATCH 1/2] Move graphic-related coalesced MMIO flushes to affected device models
Date: Tue, 18 Oct 2011 20:06:40 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Oct 18, 2011 at 06:49:57PM +0200, Jan Kiszka wrote:
> On 2011-10-18 18:40, Avi Kivity wrote:
> > On 10/18/2011 04:30 PM, Avi Kivity wrote:
> >> This takes a while to reproduce, let me talk to gdb for a bit.
> >>
> > 
> > a vcpu exit causes kvm_flush_coalesced_mmio_buffer() to run, which does
> > a bitblt, which is cirrus_do_copy(), which goes to vga_hw_update, which
> 
> Why does it have to do vga_hw_update? Why can't it set some flag for the
> next requested screen update or so? Just thinking, haven't looked at the
> code yet.

bottomhalf?

> 
> Do you think that only cirrus is affected by this pattern?
> 
> > does vga_update_display(), which calls
> > qemu_flush_coalesced_mmio_buffer(), which is not reentrant.
> > 
> > It's easy to make qemu_flush_coalesced_mmio_buffer reentrant:
> > 
> >   if (s->coalesced_flush_in_progress) {
> >       return;
> >   }
> > 
> > it isn't very pretty and is also a lie.  Other ideas?
> > 
> > I'll probably commit this soon to avoid the regression, to be replaced
> > by a better fix when we find it.
> > 
> 
> Agreed. Unless we can avoid that recursion at devices level, there is
> likely no alternative.
> 
> Jan
> 
> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]