Re: [Qemu-devel] [PATCH 0/3] Memory API mutators

[Avi Kivity <avi@redhat.com>]

On 09/14/2011 12:56 PM, Peter Maydell wrote:
> On 14 September 2011 10:23, Avi Kivity<avi@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