From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGUAn-0004r5-Fn for qemu-devel@nongnu.org; Wed, 19 Oct 2011 07:19:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGUAh-0001ky-7j for qemu-devel@nongnu.org; Wed, 19 Oct 2011 07:19:01 -0400 Received: from thoth.sbs.de ([192.35.17.2]:34835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGUAg-0001kr-Ro for qemu-devel@nongnu.org; Wed, 19 Oct 2011 07:18:55 -0400 Message-ID: <4E9EB212.1080203@siemens.com> Date: Wed, 19 Oct 2011 13:18:42 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4E859A72.9040007@siemens.com> <4E9D8698.3060608@redhat.com> <4E9D87B0.5070009@siemens.com> <4E9D884B.30309@redhat.com> <4E9D88C9.1010804@siemens.com> <4E9D8D81.308@redhat.com> <4E9DAC02.4040208@redhat.com> <4E9DAE35.4010003@siemens.com> <4E9DB892.5060602@redhat.com> <4E9DD88D.2090004@web.de> <4E9E9294.8020908@redhat.com> In-Reply-To: <4E9E9294.8020908@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] Move graphic-related coalesced MMIO flushes to affected device models List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , qemu-devel , David Gibson On 2011-10-19 11:04, Avi Kivity wrote: > > On 10/18/2011 09:50 PM, Jan Kiszka wrote: >> On 2011-10-18 19:34, Avi Kivity wrote: >>> On 10/18/2011 06:49 PM, 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. >>> >>> Maybe it's a remnant from the days where it asked the host hardware to >>> do the blt. > >> If it's no longer needed - drop it? Already for other reasons like >> efficiency. > > I think it actually is needed - it calls qemu_console_copy() to do the > copy. Which incidentally means the the coalesced flush, had it worked, > would be a bug: it would bring pending mmio writes in front of a > currently executing bitblt. I don't think we can regard my hack as a > fix for that. Maybe we need to revert the original patch. Or make sure > the flush only happens from the display thread. I hope we can avoid the old scheme as it hurts when trying to make progress /wrt scalability. Will have a look if we can avoid the recursion in some reasonable way at device level here. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux