Re: [Qemu-devel] [PATCH] 64 bit I/O support v7

[Robert Reif <reif@earthlink.net>]

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