From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ht5aB-0005fM-FT
	for qemu-devel@nongnu.org; Tue, 29 May 2007 13:34:07 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ht5a9-0005fA-3c
	for qemu-devel@nongnu.org; Tue, 29 May 2007 13:34:06 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ht5a8-0005f7-U3
	for qemu-devel@nongnu.org; Tue, 29 May 2007 13:34:04 -0400
Received: from ug-out-1314.google.com ([66.249.92.172])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1Ht5a8-0007JA-Dg
	for qemu-devel@nongnu.org; Tue, 29 May 2007 13:34:04 -0400
Received: by ug-out-1314.google.com with SMTP id a2so1776437ugf
	for <qemu-devel@nongnu.org>; Tue, 29 May 2007 10:34:03 -0700 (PDT)
Message-ID: <f43fc5580705291034n7f33d02eg8a5293144187b438@mail.gmail.com>
Date: Tue, 29 May 2007 20:34:02 +0300
From: "Blue Swirl" <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] Regression bug
In-Reply-To: <2765066.1180444125665.JavaMail.root@eastrmwml26.mgt.cox.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2765066.1180444125665.JavaMail.root@eastrmwml26.mgt.cox.net>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: sol10x86@cox.net, qemu-devel@nongnu.org
Cc: risc@volumehost.com

On 5/29/07, Ben Taylor <sol10x86@cox.net> wrote:
> Looks like the patch from http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.96&r2=1.97
> needs to be reverted and reworked before being recommitted.

Thank you for the reports. I still can't reproduce the bug, but it
seems that on PC, the area between 0xa0000 and 0x100000 is registered
multiple times and this could confuse the subpage code.

Adding printf to cpu_register_physical memory reveals:
cpu_register_physical_memory: start_addr 00000000000a0000 size 1000 phys_offset
70
cpu_register_physical_memory: start_addr 00000000000a0000 size 1000 phys_offset
70
cpu_register_physical_memory: start_addr 00000000000a0000 size 1000 phys_offset
70
cpu_register_physical_memory: start_addr 00000000000a0000 size 1000 phys_offset
70
cpu_register_physical_memory: start_addr 00000000000a0000 size 1000 phys_offset
70
cpu_register_physical_memory: start_addr 00000000000a0000 size 20000 phys_offset
 70
cpu_register_physical_memory: start_addr 00000000000a0000 size 20000 phys_offset
 a0000

The subpage part in cpu_register_physical_memory could be disabled
just for i386. A better fix would be to fix the PC/VGA/PIIX memory
registrations and also make the subpage code handle this case.