From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LzwcV-0001q2-VM for qemu-devel@nongnu.org; Fri, 01 May 2009 13:33:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LzwcR-0001nJ-1E for qemu-devel@nongnu.org; Fri, 01 May 2009 13:33:55 -0400 Received: from [199.232.76.173] (port=40860 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LzwcQ-0001nG-R0 for qemu-devel@nongnu.org; Fri, 01 May 2009 13:33:50 -0400 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]:42789) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LzwcQ-0003mQ-Ho for qemu-devel@nongnu.org; Fri, 01 May 2009 13:33:50 -0400 Message-ID: <49FB3197.3000805@earthlink.net> Date: Fri, 01 May 2009 13:29:59 -0400 From: Robert Reif 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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Paul Brook , qemu-devel@nongnu.org Blue Swirl wrote: > On 5/1/09, 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. >> > > 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. > > > > This sounds like the way to go. The device would only need to support its natural bus width and a higher level bus driver would be responsible for doing the bus width conversion or faulting. This moves the bus width conversion code from each driver up to a specific bus driver. The bus driver could be a simple as converting NULL to helper functions.