From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1M03Hn-00018s-En
	for qemu-devel@nongnu.org; Fri, 01 May 2009 20:40:59 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1M03Hi-00011U-MR
	for qemu-devel@nongnu.org; Fri, 01 May 2009 20:40:59 -0400
Received: from [199.232.76.173] (port=41367 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1M03Hi-00011J-AS
	for qemu-devel@nongnu.org; Fri, 01 May 2009 20:40:54 -0400
Received: from mx20.gnu.org ([199.232.41.8]:44600)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1M03Hi-00019C-20
	for qemu-devel@nongnu.org; Fri, 01 May 2009 20:40:54 -0400
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1M03Hh-0004dc-7i
	for qemu-devel@nongnu.org; Fri, 01 May 2009 20:40:53 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] 64 bit I/O support v7
Date: Sat, 2 May 2009 01:40:46 +0100
References: <49EDB109.5010009@earthlink.net>
	<200905011633.42946.paul@codesourcery.com>
	<49FB8D85.7010009@earthlink.net>
In-Reply-To: <49FB8D85.7010009@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200905020140.46622.paul@codesourcery.com>
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: qemu-devel@nongnu.org
Cc: Robert Reif <reif@earthlink.net>

> > 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.
>
> 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.

I'm not sure what you're suggesting. I've yet to see any actual use of the 
subwidth code, and the subpage stuff is fairly rare. 

Trying to push the subpage code down into the TLB handler might be possible, 
but you'd have to be careful to avoid performance regressions in the common 
code.

Paul