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.