On 21 March 2013 22:43, Scott Wood <scottw...@freescale.com> 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. This code isn't the first use of the memory API listeners, so it's all well-tested code. >> 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? -- PMM
