On 05/18/2011 06:36 PM, Jan Kiszka wrote:
>
> We need to head for the more hardware-like approach. What happens when
> you program overlapping BARs? I imagine the result is
> implementation-defined, but ends up with one region decoded in
> preference to the other. There is simply no way to reject an
> overlapping mapping.
But there is also now simple way to allow them. At least not without
exposing control about their ordering AND allowing to hook up managing
code (e.g. of the PCI bridge or the chipset) that controls registrations.
What about memory_region_add_subregion(..., int priority) as I suggested
in another message?
Regarding bridges, every registration request flows through them so they
already have full control.
...
>> See [1]: We really need to get rid of slot management on
>> CPUPhysMemoryClient side. Your API provides a perfect opportunity to
>> establish the infrastructure of slot tracking at a central place. We can
>> then switch from reporting cpu_registering_memory events to reporting
>> coalesced changes to slots, those slot that also the core uses. So a new
>> CPUPhysMemoryClient API needs to be considered in this API change as
>> well - or we change twice in the end.
>
> The kvm memory slots (and hopefully future qemu memory slots) are a
> flattened view of the MemoryRegion tree. There is no 1:1 mapping.
We need a flatted view of your memory regions during runtime as well. No
major difference here. If we share that view with PhysMemClients, they
can drop most of their creative slot tracking algorithms, focusing on
the real differences.
We'll definitely have a flattened view (phys_desc is such a flattened
view, hopefully we'll have a better one).
We can basically run a tree walk on each change, emitting ranges in
order and sending them to PhysMemClients.
--
error compiling committee.c: too many arguments to function
