From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Lzvir-0006BM-DC
	for qemu-devel@nongnu.org; Fri, 01 May 2009 12:36:25 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Lzvim-0005yA-IX
	for qemu-devel@nongnu.org; Fri, 01 May 2009 12:36:24 -0400
Received: from [199.232.76.173] (port=48162 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Lzvim-0005xp-Ci
	for qemu-devel@nongnu.org; Fri, 01 May 2009 12:36:20 -0400
Received: from mail-bw0-f175.google.com ([209.85.218.175]:54633)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <edgar.iglesias@gmail.com>) id 1Lzvim-0004ii-1U
	for qemu-devel@nongnu.org; Fri, 01 May 2009 12:36:20 -0400
Received: by bwz23 with SMTP id 23so2158469bwz.34
	for <qemu-devel@nongnu.org>; Fri, 01 May 2009 09:36:18 -0700 (PDT)
Date: Fri, 1 May 2009 18:36:14 +0200
From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Subject: Re: [Qemu-devel] [PATCH] 64 bit I/O support v7
Message-ID: <20090501163614.GA12010@laped.iglesias.mooo.com>
References: <49EDB109.5010009@earthlink.net>
	<200905011552.48991.paul@codesourcery.com>
	<49FB1302.4090904@earthlink.net>
	<200905011633.42946.paul@codesourcery.com>
	<f43fc5580905010851x5680f65btd8c2eabb71aaa73a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f43fc5580905010851x5680f65btd8c2eabb71aaa73a@mail.gmail.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: Blue Swirl <blauwirbel@gmail.com>
Cc: Robert Reif <reif@earthlink.net>, Paul Brook <paul@codesourcery.com>, qemu-devel@nongnu.org

On Fri, May 01, 2009 at 06:51:08PM +0300, Blue Swirl wrote:
> On 5/1/09, Paul Brook <paul@codesourcery.com> 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.
> 
> Maybe the registration could also be changed so that if the device
> only cares for (say) 16 bits (and does not want trapping for the wrong
> sized access), the 64, 32 and 8 bit cases are emulated at higher
> level. This would shrink the code base a bit and maybe fits to the bus
> model.

I'd appreciate something along these lines :)

Cheers