Re: [Qemu-devel] [RFC] Memory API

[Avi Kivity]

On 05/19/2011 05:15 PM, Anthony Liguori wrote:
> Except for priorities.
>
> If you've got a hierarchy like:
>
> - CPU:0
>  - i440fx:1
>    - PIIX3:2
>      - ISA:3
>        - DeviceA
>    - PCI:2
>      - DeviceB
>
> In your model, the default priorities are as shown, but nothing stops 
> DeviceB from registering with a priority of 0 which means it can 
> intercept accesses that would normally go to the i440fx.

Priorities are only within the parent region.  DeviceB's priorities have 
no effect whatsoever since it is an only child.

(and btw the intent is to have higher priorities hide lower priorities).

The model is that of a nested window system with transparent windows.

> This is impossible in a hierarchical dispatch model.  There is no 
> setting that a PCI device can use to trap accesses that the i440fx 
> would normally take.
>
> I don't mind if we don't have hierarchical dispatch to start with, but 
> priorities are fundamentally broken.

Are not.

> > We could easily have the implementation
> > walk the memory hierarchy to dispatch an mmio.
> >
> > However, RAM cannot be dispatched this way (we need to resolve which
> > ranges are RAM when the regions are registered, not accessed) so a data
> > structure that contains all of the information is mandatory.
>
> There is only one device that is capable of affecting the view of 
> RAM--the i440fx PMC.  The reason is simple, the i440fx is the thing 
> that sends a request from a CPU either to a DIMM or to some device.  
> It doesn't know which device it goes to and it doesn't care.
>
> That's where the RAM mapping lives.  It doesn't matter how the PCI I/O 
> window is split up.  You don't need that information to know where RAM 
> is.

There is also RAM in the framebuffer and the vga windows.  It moves around.

--
error compiling committee.c: too many arguments to function