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

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/19/2011 08:53 AM, Avi Kivity wrote:
> On 05/19/2011 04:49 PM, Anthony Liguori wrote:
>> On 05/19/2011 08:30 AM, Avi Kivity wrote:
>>> On 05/19/2011 04:26 PM, Jan Kiszka wrote:
>>>> On 2011-05-19 15:07, Avi Kivity wrote:
>>
>>>> And when introducing hierarchical registration, we will have to go
>>>> through all of this once again. Plus the API may have to be changed
>>>> again if it does not fulfill all requirements of the hierarchical
>>>> region
>>>> management. And we have no proof that it allows an efficient core
>>>> implementation.
>>>
>>> This API *is* hierarchical registration. v2 will (hopefully) prove that
>>> it can be done efficiently.
>>
>> We also need hierarchical dispatch. Priorities are just a weak attempt
>> to emulate hierarchical dispatch but I don't think there's an
>> improvement over a single dispatch table.
>>
>> Hierarchical dispatch is simpler. You just need a simple list at each
>> bus.
>>
>
> The API itself says nothing about whether the hierarchy is evaluated at
> run-time or registration time.

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.

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.

> 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.

Regards,

Anthony Liguori