From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:37001)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1RGANA-0005mO-Lo
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 10:10:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1RGAN5-0004ie-Of
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 10:10:28 -0400
Received: from thoth.sbs.de ([192.35.17.2]:21022)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1RGAN5-0004iG-07
	for qemu-devel@nongnu.org; Tue, 18 Oct 2011 10:10:23 -0400
Message-ID: <4E9D88C9.1010804@siemens.com>
Date: Tue, 18 Oct 2011 16:10:17 +0200
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <4E859A72.9040007@siemens.com> <4E9D8698.3060608@redhat.com>
	<4E9D87B0.5070009@siemens.com> <4E9D884B.30309@redhat.com>
In-Reply-To: <4E9D884B.30309@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: <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: Avi Kivity <avi@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel <qemu-devel@nongnu.org>, David Gibson <david@gibson.dropbear.id.au>

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"? I was under the
impression winxp is missing our periodic flushes. Do things work again
when you do not flush at all?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux