Re: [Qemu-devel] [PATCH 4/5] integratorcp: convert integratorcm to VMState

[Avi Kivity <avi@redhat.com>]

On 11/08/2011 02:15 PM, Peter Maydell wrote:
> >>
> >> Avi, ping? I'm still interested in the answer to this question.
> >
> > Sorry, missed this. Yes, you need to ensure the memory region mapping
> > reflects flash_mapped.
>
> This needs to be in the MemoryRegion core implementation, please.

Right; see the memory/mutators branch.  I plan to push this as soon as
everything is converted.

> I don't want to have to redo it for every device that has a
> remappable region. In particular, at the moment memory.c's
> add/delete region functions will assert if the region was already
> added/deleted, which means the device has to keep track in a
> not-vm-saved state flag whether the memory was mapped so it can
> resync things on load (by comparing the non-saved flag and the
> saved-state).
>
> Ideally memory.c should just ensure that the memory hierarchy
> is saved and restored without devices having to do anything.

That's a bit far-fetched - I don't want the memory core involved in
save/restore.  But if/when we integrate the memory core into QOM, then
yes, that layer can take care of it.  If we have an observable attribute
(that fires off a callback when changed), we can link memory API
properties into that attribute.

> > btw, is flash_mapped a real device state (corresponds to a real memory
> > bit on the device) or just an artefact?  It's usually a bad idea to cast
> > implementation artefacts in vmstate concrete.
>
> It's an implementation artefact that you introduced when you
> did the memoryregion conversion :-)
>
> I have a half-a-patch to fix that lurking somewhere but it
> stalled because at the moment the non-saved flag is required
> in order to work around memory.c being unhelpful.

Ideally we'd have a way to separate implementation state from real state
(after working hard to eliminate implementation state).

-- 
error compiling committee.c: too many arguments to function