From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lzv15-0000MY-1D for qemu-devel@nongnu.org; Fri, 01 May 2009 11:51:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lzv14-0000M1-9o for qemu-devel@nongnu.org; Fri, 01 May 2009 11:51:10 -0400 Received: from [199.232.76.173] (port=53656 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lzv14-0000Ly-3g for qemu-devel@nongnu.org; Fri, 01 May 2009 11:51:10 -0400 Received: from fg-out-1718.google.com ([72.14.220.156]:33023) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lzv13-0004hY-KN for qemu-devel@nongnu.org; Fri, 01 May 2009 11:51:09 -0400 Received: by fg-out-1718.google.com with SMTP id l27so86606fgb.8 for ; Fri, 01 May 2009 08:51:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <200905011633.42946.paul@codesourcery.com> References: <49EDB109.5010009@earthlink.net> <200905011552.48991.paul@codesourcery.com> <49FB1302.4090904@earthlink.net> <200905011633.42946.paul@codesourcery.com> Date: Fri, 1 May 2009 18:51:08 +0300 Message-ID: Subject: Re: [Qemu-devel] [PATCH] 64 bit I/O support v7 From: Blue Swirl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org, Robert Reif 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.