Re: [Qemu-devel] qemu cpu-all.h exec.c

[Paul Brook <paul@codesourcery.com>]

On Thursday 03 January 2008, Blue Swirl wrote:
> On 1/3/08, Paul Brook <paul@codesourcery.com> wrote:
> > On Wednesday 02 January 2008, Blue Swirl wrote:
> > > On 1/2/08, Paul Brook <paul@codesourcery.com> wrote:
> > > > > Also the opaque parameter may need to be different for each
> > > > > function, it just didn't matter for the unassigned memory case.
> > > >
> > > > Do you really have systems where independent devices need to respond
> > > > to different sized accesses to the same address?
> > >
> > > I don't think so. But one day unassigned or even normal RAM memory
> > > access may need an opaque parameter, so passing the device's opaque to
> > > unassigned memory handler is wrong.
> >
> > I'm not convinced.  Your current implementation seems to introduce an
> > extra level of indirection without any plausible benefit.
> >
> > If you're treating unassigned memory differently it needs to be handled
> > much earlier that so you can raise CPU exceptions.
>
> Earlier, where's that?

Probably when populating the TLB entry. IIRC by the time we get to the IO 
callbacks we don't have enough information to generate a CPU exception.

> Another approach could be conditional stacked handlers, where a higher
> level handler could pass the access request to lower one (possibly
> modifying it in flight) or handle completely. Maybe this solves the
> longstanding generic DMA issue if taken to the device to memory
> direction.

I'm not so sure. RAM is special because it's direct mapped by the TLB rather 
than going through the (much slower) MMIO handling routines.

Paul