Re: [Qemu-devel] [PATCH 4/5] milkymist-softusb: Don't map RAM memory regions in the device itself

[Peter Maydell]

On 15 February 2013 16:06, Paolo Bonzini <address@hidden> 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