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

[Blue Swirl <blauwirbel@gmail.com>]

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.