From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:37195)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RGAge-0002cY-UU
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 10:30:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RGAga-00015O-Ow
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 10:30:36 -0400
Received: from mx1.redhat.com ([209.132.183.28]:28578)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1RGAga-00015D-DI
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 10:30:32 -0400
Message-ID: <4E9D8D81.308@redhat.com>
Date: Tue, 18 Oct 2011 16:30:25 +0200
From: Avi Kivity <avi@redhat.com>
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>
In-Reply-To: <4E9D88C9.1010804@siemens.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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel <qemu-devel@nongnu.org>, David Gibson <david@gibson.dropbear.id.au>

On 10/18/2011 04:10 PM, Jan Kiszka wrote:
> On 2011-10-18 16:08, Avi Kivity wrote:
> > On 10/18/2011 04:05 PM, Jan Kiszka wrote:
> >> On 2011-10-18 16:00, Avi Kivity wrote:
> >>> On 09/30/2011 01:31 PM, Jan Kiszka wrote:
> >>>> This is conceptually cleaner and will allow us to drop the nographic
> >>>> timer. Moreover, it will be mandatory to fully exploit future per-device
> >>>> coalesced MMIO rings.
> >>>>
> >>>
> >>> Appears to break winxp installation - the guest enters an infinite
> >>> bitblt loop.  Trying to find out why.
> >>
> >> Hmm, maybe there are side effects in certain modes that actually
> >> disallow coalescing.
> >>
> > 
> > That's true for sure, but flushing the buffer should never be wrong.
>
> Err, you mean we are not flushing "too often"? 

No, I don't know what the exact problem is.  What I mean is that an
extra flush should never hurt; a missing flush degrades the user
experience but shouldn't cause the infinite loops I'm seeing.

> I was under the
> impression winxp is missing our periodic flushes. Do things work again
> when you do not flush at all?

This takes a while to reproduce, let me talk to gdb for a bit.

-- 
error compiling committee.c: too many arguments to function