[Top][All Lists]

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

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

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/3] Memory API mutators
Date: Wed, 14 Sep 2011 13:02:54 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

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

reply via email to

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