On 2012-09-05 12:53, Avi Kivity wrote: > On 09/05/2012 01:36 PM, Jan Kiszka wrote: >>> >>> My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (and a >>> corresponding unref), which has the following requirements: >>> >>> - if the refcount is nonzero, MemoryRegion::opaque is safe to use >>> - if the refcount is nonzero, the MemoryRegion itself is stable. >> >> The second point means that the memory subsystem will cache the region >> state and apply changes only after leaving a handler that performed them? > > No. I/O callbacks may be called after a region has been disabled. > > I guess we can restrict this to converted regions, so we don't introduce > regressions.
s/can/have to/. This property change will require some special care, hopefully mostly at the memory layer. A simple scenario from recent patches: if (<enable>) { memory_region_set_address(&s->pm_io, pm_io_base); memory_region_set_enabled(&s->pm_io, true); } else { memory_region_set_enabled(&s->pm_io, false); } We will have to ensure that set_enabled(..., true) will never cause a dispatch using an outdated base address. I think discussing semantics and usage patterns of the new memory API - outside of the BQL - will be the next big topic. ;) Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux