From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LzukK-00039l-Bg for qemu-devel@nongnu.org; Fri, 01 May 2009 11:33:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LzukF-00038f-7D for qemu-devel@nongnu.org; Fri, 01 May 2009 11:33:51 -0400 Received: from [199.232.76.173] (port=57746 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LzukF-00038c-1O for qemu-devel@nongnu.org; Fri, 01 May 2009 11:33:47 -0400 Received: from mx20.gnu.org ([199.232.41.8]:12909) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LzukE-00021g-Qy for qemu-devel@nongnu.org; Fri, 01 May 2009 11:33:46 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LzukD-0004Kg-SJ for qemu-devel@nongnu.org; Fri, 01 May 2009 11:33:46 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] 64 bit I/O support v7 Date: Fri, 1 May 2009 16:33:42 +0100 References: <49EDB109.5010009@earthlink.net> <200905011552.48991.paul@codesourcery.com> <49FB1302.4090904@earthlink.net> In-Reply-To: <49FB1302.4090904@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905011633.42946.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Robert Reif Cc: qemu-devel@nongnu.org > > 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