|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC] Memory API |
Date: | Thu, 19 May 2011 09:15:38 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 |
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 - DeviceBIn 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
[Prev in Thread] | Current Thread | [Next in Thread] |