[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_add

From: Scott Wood
Subject: Re: [Qemu-ppc] [RFC ppc-next PATCH 3/6] memory: add memory_region_to_address()
Date: Fri, 22 Mar 2013 17:05:13 -0500

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]