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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-05-19 16:15, Anthony Liguori wrote:
> 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.

Priorities would be local, so the normal tree would look like this:

 - CPU:0
   - i440fx:0
     - PIIX3:0
       - DeviceA
     - PCI-DeviceB:0

If the i440fx would like to map something different over DeviceA (or
parts of it), it would create a region of prio 1 or higher.

The same would happen at CPU-level with SMRAM when SMM is entered.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux