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

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Fri, May 01, 2009 at 06:51:08PM +0300, 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.

I'd appreciate something along these lines :)

Cheers