On Wed, Mar 14, 2012 at 10:57:15AM -0500, Anthony Liguori wrote:
> On 03/14/2012 10:54 AM, Gleb Natapov wrote:
> >On Wed, Mar 14, 2012 at 10:42:50AM -0500, Anthony Liguori wrote:
> >>
> >>There's still a few places in QEMU that assume that
> >>qemu_ram_get_ptr() returns a pointer that's good indefinitely.
> >>
> >>We also don't have a mechanism to revoke cpu_physical_map()
> >>pointers. Maybe the answer is reference counting and relying on
> >>being able to eventually release the memory... Of course, then an
> >>unplug followed by an immediate plug would be complicated.
> >>
> >Hmm, Avi assured me that with the memory API rework it should be easy :(
> >grep founds nothing about qemu_ram_get_ptr() and cpu_physical_map()
> >though. What should I look for?
>
> memory_region_get_ptr() and cpu_memory_physical_map().
>
cpu_physical_memory_map() and qemu_get_ram_ptr() (called only via
memory_region_get_ram_ptr() by device model). According to
qemu_get_ram_ptr() comment it should be used only to access device
memory, not RAM (it is also used in softmmu code, but lets leave this
for now :)).
cpu_physical_memory_map() is used for DMA. When guest confirms memory
removal by calling _EJ() ACPI methods no DMA should be directed to that
memory slot. We can refcount slot during map/unmap and do not remove a
slot it refcount > 0, or we can kill guest if this happens. That what
real HW would do.
--
Gleb.
