On 15 February 2013 16:06, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 15/02/2013 16:35, Peter Maydell ha scritto: >>> > I think it's best to avoid storing long-lived host pointers. Ideally we >>> > should have no long-lived host pointers anytime the thread is quiescent >>> > (for CPUs that means kvm_cpu_exec or the end of qemu_tcg_wait_io_event; >>> > for I/O that means select/poll). >>> > >>> > Can you call memory_region_get_ram_ptr from the read/write functions? >> I could, but does it buy us anything in particular? (alternatively, >> what's the reason why we should avoid storing the host pointers? >> We do it in a number of other devices...) > > I find it more complex to reason about finer-grained locking > (particularly regarding the lifetimes) when you have object A storing > something into object B. In practice it should be handled just fine by > reference counting, but I still find it harder to wrap my head around it.
But these memory regions belong to this device -- we own them and they won't go away until the device is destroyed [which is never, as it happens, for this device.] More generally, if it's valid for us to hold a MemoryRegion* and call memory_region_get_ram_ptr() in the read/write function, it's just as valid to keep the ram pointer: the two have exactly matching lifetimes, unless I'm missing something. (as an aside, memory_region_destroy() doesn't free the memory that memory_region_init_ram() allocates.) -- PMM
