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
