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

[Blue Swirl]

On 1/3/08, Fabrice Bellard <address@hidden> wrote:
> Blue Swirl wrote:
> > On 1/3/08, Paul Brook <address@hidden> wrote:
> >> On Wednesday 02 January 2008, Blue Swirl wrote:
> >>> On 1/2/08, Paul Brook <address@hidden> 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?
> >
> > 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.
>
> As I said earlier, the only correct way to handle memory accesses is to
> be able to consider a memory range and its associated I/O callbacks as
> an object which can be installed _and_ removed. It implies that there is
> a priority system close to what you described. It is essential to
> correct long standing PCI bugs for example.

This should be feasible, though raises a few questions. Does this mean
another API for stacked registration, or should stacking happen
automatically with current API? A new function is needed for removal.

What could be the API for setting priorities? How would multiple
layers be enabled for multiple devices at same location? How can a
higher level handler pass the request to lower one? Do we need a
status return for access handler?

A few use cases:
Partial width device > unassigned
ROM > RAM > unassigned
SBus controller > EBus controller > Device > unassigned

Other direction (for future expansion):
Device > DMA controller > SBus controller > IOMMU > RAM > unassigned