|
| From: | Avi Kivity |
| Subject: | Re: [Qemu-devel] [RFC] Memory API |
| Date: | Fri, 20 May 2011 11:56:05 +0300 |
| User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 |
On 05/19/2011 07:36 PM, Anthony Liguori wrote:
There are no global priorities. Priorities are only used inside each level of the memory region hierarchy to generate a resulting, flattened view for the next higher level. At that level, everything imported from below has the default prio again, ie. the lowest one.Then SMM is impossible.
It doesn't follow.
Why do we need priorities at all? There should be no overlap at each level in the hierarchy.
Of course there is overlap. PCI BARs overlap each other, the VGA windows and ROM overlap RAM.
If you have overlapping BARs, the PCI bus will always send the request to a single device based on something that's implementation specific. This works because each PCI device advertises the BAR locations and sizes in it's config space.
BARs in general don't need priority, except we need to decide if BARs overlap RAM of vice-versa.
To dispatch a request, the PCI bus will walk the config space to find a match. If you remove something that was previously causing an overlap, it'll the other device will now get the I/O requests.
That's what *exactl* what priority means. Which device is in front, and which is in the back.
To model this correctly, you need to let the PCI bus decide how to dispatch I/O requests (again, you need hierarchical dispatch).
And again, this API gives you hierarchical dispatch, with the addition that some of it is done at registration time so we can prepare the RAM slots.
In the absence of this, the PCI bus needs to look at all of the devices, figure out the flat mapping, and register it. When a device is added or removed, it needs to recalculate the flat mapping and register it.
However we do this, we need to look at all devices.
There is no need to have centralized logic to decide this.
I think you're completely missing the point of my proposal. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
| [Prev in Thread] | Current Thread | [Next in Thread] |