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

["Blue Swirl" <blauwirbel@gmail.com>]

On 1/3/08, Paul Brook <paul@codesourcery.com> wrote:
> > > 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?
>
> I don't think "passing through" requests to the next handler is an interesting
> use case.  Just consider a device to handle all accesses within its defined
> region.
>
> If an overlapping region is accessed then at best you're into highly machine
> dependent behavior. The only interesting case I can think of is x86 where a
> PCI region may be overlayed on top of RAM. A single level of priority
> (ram/rom vs. everything else) is probably sufficient for practical purposes.
>
> The most important thing is that when one of the mappings is removed,
> subsequent accesses to the previously overlapped region hit the remaining
> device.

The difference between "passive" stacking and "active" should be
minimal and not visible to the devices.

> > 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
>
> I think these are different things:
>
> - Registering multiple devices within the same address space.
> - Mapping access from one address sapce to annother.
>
> Currently qemu does neither.
>
> The former is what Fabrice is talking about.

Right, but if we have this "active" stacking, address translation
could be a possible future extension of this mode.

> The latter depends how general you want the solution to be. One possibility is
> for the device DMA+registration routines map everything onto CPU address
> space.

Interesting idea, do you mean that all individual bus address spaces
could exist in system view in the same large address space outside the
target CPU address space? Then some of the translations could become
simple offset operations.