From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1M02k6-0005wR-6x
	for qemu-devel@nongnu.org; Fri, 01 May 2009 20:06:10 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1M02k1-0005qb-GW
	for qemu-devel@nongnu.org; Fri, 01 May 2009 20:06:09 -0400
Received: from [199.232.76.173] (port=38767 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1M02k1-0005qO-AO
	for qemu-devel@nongnu.org; Fri, 01 May 2009 20:06:05 -0400
Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]:34540)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <reif@earthlink.net>) id 1M02k0-0008BY-OQ
	for qemu-devel@nongnu.org; Fri, 01 May 2009 20:06:04 -0400
Message-ID: <49FB8D85.7010009@earthlink.net>
Date: Fri, 01 May 2009 20:02:13 -0400
From: Robert Reif <reif@earthlink.net>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] 64 bit I/O support v7
References: <49EDB109.5010009@earthlink.net>	<200905011552.48991.paul@codesourcery.com>	<49FB1302.4090904@earthlink.net>
	<200905011633.42946.paul@codesourcery.com>
In-Reply-To: <200905011633.42946.paul@codesourcery.com>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org

Paul Brook wrote:
>>> sparc hardware is rather abnormal (for qemu at least) because it cares
>>> what happens when you use the wrong width. Most devices don't care, and
>>> having any NULL functions is liable to introduce significant overhead.
>>>       
>> Ok, so that explains the curious code in m48t59.c:
>> ...
>> So nvram_writeq should be present on non sparc architectures
>> and actually should be doing 8 byte accesses?  How do we handle
>> architecture differences like this?  On sparc, it looks like the
>> sbus controller does this because the actual hardware really
>> only has an 8 bit bus.
>>     
>
> Are there actually any cases where this matters?
>
> My guess is that in pactice we only have certain SPARC devices that need to 
> trap when you do a wrong sized access, and for everything else you're told 
> not to do that, and qemu can happily return garbage.
>
> If this is the case then the IO_MEM_SUBWIDTH code seems like complete 
> overkill. I reccommend ripping it out, and maybe having the registration 
> function replace NULL with the unassigned hander.
>
> Paul
>
>
>
>   
Wouldn't making a version of the subpage structure the default
and getting rid of the multiple parallel arrays make more sense.
Then there would only be one type of I/O memory and no special
cases.