qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/7] Convert pc cpu to qdev


From: Gleb Natapov
Subject: Re: [Qemu-devel] [PATCH 2/7] Convert pc cpu to qdev
Date: Wed, 14 Mar 2012 18:27:04 +0200

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]