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

[Jan Kiszka]

On 2011-05-19 18:36, Anthony Liguori wrote:
> On 05/19/2011 11:30 AM, Jan Kiszka wrote:
>> On 2011-05-19 18:28, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 06:25:14PM +0200, Jan Kiszka wrote:
>>>> On 2011-05-19 18:17, Gleb Natapov wrote:
>>>>> On Thu, May 19, 2011 at 05:40:50PM +0300, Avi Kivity wrote:
>>>>>> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
>>>>>>>
>>>>>>> So....  do you do:
>>>>>>>
>>>>>>> isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
>>>>>>> {
>>>>>>>     chipset_register_region(bus->chipset, mr, priority + 1);
>>>>>>> }
>>>>>>>
>>>>>>> I don't really understand how you can fold everything into one
>>>>>>> table and not allow devices to override their parents using
>>>>>>> priorities.
>>>>>>
>>>>>> Think of how a window manager folds windows with priorities onto a
>>>>>> flat framebuffer.
>>>>>>
>>>>>> You do a depth-first walk of the tree.  For each child list, you
>>>>>> iterate it from the lowest to highest priority, allowing later
>>>>>> subregions override earlier subregions.
>>>>>>
>>>>> And how you set those priorities in a sensible way? Why two device on a
>>>>> PCI bus will want to register their memory region with anything but
>>>>> highest priority? And if you let PCI subsystem to assign priorities how
>>>>> it will coordinate with ISA subsystem/memory controller what priorities
>>>>> to assign to get meaningful system?
>>>>
>>>> Priorities>default will only be used for explicit overlays, e.g. RAM
>>>> over MMIO in PAM regions. Non-default priorities won't be assigned to
>>>> normal PCI bars or any other device's region.
>>>>
>>> That does not explain who and how assign those priorities in globally
>>> meaningful way.
>>
>> 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.

For sure it is. The CPU and the chipset, each at their mapping level,
create a corresponding RAM region and register it with higher prio at
the SMRAM start address (CPU and chipset will need to exchange that
address or otherwise coordinate the mapping information - the price for
per-CPU SMRAM).

> 
> Why do we need priorities at all?  There should be no overlap at each 
> level in the hierarchy.
> 
> 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.

That's not a use case for priorities at all. Priorities are useful for
PAM and SMRAM-like scenarios.

Jan

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