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
