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

[Avi Kivity <avi@redhat.com>]

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