From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:46775)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <andreas.faerber@web.de>) id 1RUn1g-0007Jq-HI
	for qemu-devel@nongnu.org; Sun, 27 Nov 2011 17:16:45 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <andreas.faerber@web.de>) id 1RUn1f-0001OT-Ci
	for qemu-devel@nongnu.org; Sun, 27 Nov 2011 17:16:44 -0500
Received: from mout.web.de ([212.227.15.4]:58421)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <andreas.faerber@web.de>) id 1RUn1f-0001O9-2D
	for qemu-devel@nongnu.org; Sun, 27 Nov 2011 17:16:43 -0500
Message-ID: <4ED2B6A1.7000102@web.de>
Date: Sun, 27 Nov 2011 23:16:01 +0100
From: =?ISO-8859-15?Q?Andreas_F=E4rber?= <andreas.faerber@web.de>
MIME-Version: 1.0
References: <4ECD88EF.2030200@web.de> <4ECFC162.5050408@web.de>
	<4ED1F58D.1080809@redhat.com> <4ED2440B.9060709@web.de>
	<4ED2465E.9010709@redhat.com>
In-Reply-To: <4ED2465E.9010709@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] Memory read/write issues
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: qemu-devel Developers <qemu-devel@nongnu.org>

Am 27.11.2011 15:17, schrieb Avi Kivity:
> On 11/27/2011 04:07 PM, Andreas Färber wrote:
>> Thanks a lot! You were right, setting TARGET_PAGE_BITS to 8 solves this
>> issue.
>>
>> I'd still like to fix this subpage case for others' benefit. Do you have
>> any pointer where I should set breakpoints / review code?
> 
> The subpage code (scheduled for demolition in 1.1) lives in exec.c.  See
> subpage_init() and subpage_register().  I'd start with enabling
> DEBUG_SUBPAGE, fixing all the build errors, and looking at the output of
> subpage_readlen() and subpage_writelen().

With these hints I've figured out what's actually happening here:

subpage_writelen() is reading a wrong index 2 == IO_MEM_UNASSIGNED from
subpage_t and performing an unassigned memory write, confirmed by
DEBUG_UNASSIGNED.

In subpage_register(), we're taking the (memory & ~TARGET_PAGE_MASK) ==
IO_MEM_RAM path and setting IO_MEM_UNASSIGNED in subpage_t.

Will investigate further tomorrow.

Andreas