Re: [Qemu-devel] [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address()

[Scott Wood]

On 03/22/2013 08:08:57 AM, Peter Maydell wrote:
> On 21 March 2013 22:43, Scott Wood <address@hidden> wrote:
> > What if the update is to a parent memory region, not to the one  
> directly
> > associated with the device?
> >
> > Or does add() get called for all child regions (recursively) in  
> such cases?
>
> The memory API flattens the tree of memory regions down into a flat
> view of the address space. These callbacks get called for the
> final flattened view (so you'll never see a pure container in the
> callback, only leaves). The callbacks happen for every region which
> appears in the address space, in linear order. When an update happens
> memory.c identifies the changes between the old flat view and the
> new one and calls callbacks appropriately.

OK, so .add and .del will be sufficient to capture any manipulation  
that would affect whether and where the region we care about is mapped?

> This code isn't the
> first use of the memory API listeners, so it's all well-tested code.

Sure, I'm not suggesting the code doesn't work -- just trying to  
understand how, so I know I'm using it properly.  The implementation is  
a bit opaque (to me at least), and the listener callbacks aren't  
documented the way the normal API functions are.

> >> However, maybe with a bit of brainstorming we could come up with a
> >> reasonably generic scheme.
>
> > In the kernel API?  Or do you mean a generic scheme within QEMU  
> that encodes
> > any reasonably expected mechanism for setting the device adress  
> (e.g. assume
> > that it is either a 64-bit attribute, or uses the legacy ARM API),  
> or
> > perhaps a callback into device code?
> >
> > The MPIC's memory listener isn't that much code... I'm not sure
> > there's a great need for a central KVM registry.
>
> Well, nor is the ARM memory listener, but why have two bits of
> code doing the same thing when you could have one?

They're not doing quite the same thing, though, and the effort required  
to unify them is non-zero.  The two main issues are the way that the  
address is communicated to KVM, and the ability to change the mapping  
after the guest starts.

-Scott