On 09/14/2011 12:56 PM, Peter Maydell wrote:
On 14 September 2011 10:23, Avi Kivity<a...@redhat.com> wrote:
> This patchset introduces memory_region_set_enabled() and
> memory_region_set_address() to avoid the requirement on memory
> routers to track the internal state of the memory API (so they know
> whether they need to add or remove a region). Instead, they can
> simply copy the state of the region from the guest-exposed register
> to the memory core, via the new mutator functions.
>
> Please review. Do we need a memory_region_set_size() as well?
Would set_size() allow things like omap_gpmc() to avoid the need
to create an intermediate container subregion to enforce size
clipping on the child region it's trying to map?
I'd recommend not calling _set_size() on somebody else's region - this
quickly leads to confusion. Only call set_size() if you also called
_init() and will call _destroy().
Can you point me at the code in question?
_set_size() may be useful for dynamic bridge windows and the like.
(Strictly speaking what omap_gpmc() wants is not merely clipping
to a guest-specified size but also wrapping, so you can take a
16MB child region and map the bottom 4MB of it repeating into
a 32MB chunk of address space, say. But that would require a lot
of playing games with aliases to implement a bizarre corner
case that nobody uses in practice.)
That's best done in the memory core, the rendering loop can be adjusted
to do this replication.
--
error compiling committee.c: too many arguments to function
