On Thursday 03 January 2008, Blue Swirl wrote: > On 1/3/08, Paul Brook <[EMAIL PROTECTED]> wrote: > > On Wednesday 02 January 2008, Blue Swirl wrote: > > > On 1/2/08, Paul Brook <[EMAIL PROTECTED]> 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