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

[Jan Kiszka]

On 2011-05-19 20:40, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 08:27:50PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 20:22, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 08:11:39PM +0200, Jan Kiszka wrote:
>>>> On 2011-05-19 19:39, Gleb Natapov wrote:
>>>>> On Thu, May 19, 2011 at 03:37:58PM +0200, Jan Kiszka wrote:
>>>>>> On 2011-05-19 15:36, Anthony Liguori wrote:
>>>>>>> On 05/18/2011 02:40 PM, Jan Kiszka wrote:
>>>>>>>> On 2011-05-18 15:12, Avi Kivity wrote:
>>>>>>>>> void cpu_register_memory_region(MemoryRegion *mr, target_phys_addr_t
>>>>>>>>> addr);
>>>>>>>>
>>>>>>>> OK, let's allow overlapping, but make it explicit:
>>>>>>>>
>>>>>>>> void cpu_register_memory_region_overlap(MemoryRegion *mr,
>>>>>>>>                                          target_phys_addr_t addr,
>>>>>>>>                                          int priority);
>>>>>>>
>>>>>>> The device doesn't actually know how overlapping is handled.  This is
>>>>>>> based on the bus hierarchy.
>>>>>>
>>>>>> Devices don't register their regions, buses do.
>>>>>>
>>>>> Today PCI device may register region that overlaps with any other
>>>>> registered memory region without even knowing it. Guest can write any
>>>>> RAM address into PCI BAR and this RAM address will be come mmio are. More
>>>>> interesting is what happens when guest reprogram PCI BAR to other address
>>>>> - the RAM that was at the previous address just disappears. Obviously
>>>>>   this is crazy behaviour, but the question is how do we want to handle
>>>>> it? One option is to disallow such overlapping registration, another is
>>>>> to restore RAM mapping after PCI BAR is reprogrammed. If we chose second
>>>>> one the PCI will not know that _overlap() should be called.
>>>>
>>>> BARs may overlap with other BARs or with RAM. That's well-known, so PCI
>>>> bridged need to register their regions with the _overlap variant
>>>> unconditionally. In contrast to the current PhysPageDesc mechanism, the
>>> With what priority? If it needs to call _overlap unconditionally why not
>>> always call _overlap and drop not _overlap variant?
>>
>> Because we should catch accidental overlaps in all those non PCI devices
>> with hard-wired addressing. That's a bug in the device/machine model and
>> should be reported as such by QEMU.
> Why should we complicate API to catch unlikely errors? If you want to
> debug that add capability to dump memory map from the monitor.

Because we need to switch tons of code that so far saw a fairly
different reaction of the core to overlapping regions.

> 
>>
>>>
>>>> new region management will not cause any harm to overlapping regions so
>>>> that they can "recover" when the overlap is gone.
>>>>
>>>>>
>>>>> Another example may be APIC region and PCI. They overlap, but neither
>>>>> CPU nor PCI knows about it.
>>>>
>>>> And they do not need to. The APIC regions will be managed by the per-CPU
>>>> region management, reusing the tool box we need for all bridges. It will
>>>> register the APIC page with a priority higher than the default one, thus
>>>> overriding everything that comes from the host bridge. I think that
>>>> reflects pretty well real machine behaviour.
>>>>
>>> What is "higher"? How does it know that priority is high enough?
>>
>> Because no one else manages priorities at a specific hierarchy level.
>> There is only one.
>>
> PCI and CPU are on different hierarchy levels. PCI is under the PIIX and
> CPU is on a system BUS.

The priority for the APIC mapping will be applied at CPU level, of
course. So it will override everything, not just PCI.

> 
>>> I
>>> thought, from reading other replies, that priorities are meaningful
>>> only on the same hierarchy level (which kinda make sense), but now you
>>> are saying that you will override PCI address from another part of
>>> the topology?
>>
>> Everything from below in the hierarchy is fed in with default priority,
>> the lowest one. So to let some region created at this level override
>> those regions, just pick default+1. If you want to create more overlay
>> levels (can't imagine a good scenario, though), pick
>> default+1..default+n. It's really that simple.
>>
> Except that PCI and CPU are not on the same level.

See above.

Jan

signature.asc
Description: OpenPGP digital signature