[Xen-devel] Re: [PATCH RFC V4 10/14] Introduce qemu_ram_ptr_unlock.

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

On 09/28/2010 10:25 AM, Stefano Stabellini wrote:
> On Tue, 28 Sep 2010, Anthony Liguori wrote:
>    
> > On 09/28/2010 10:01 AM, anthony.perard@xxxxxxxxxx wrote:
> >      
> > > From: Anthony PERARD<anthony.perard@xxxxxxxxxx>
> > >
> > > This function allows to unlock a ram_ptr give by qemu_get_ram_ptr. After
> > > a call to qemu_ram_ptr_unlock, the pointer may be unmap from QEMU when
> > > used with Xen.
> > >
> > > Signed-off-by: Anthony PERARD<anthony.perard@xxxxxxxxxx>
> > >
> > >        
> > Why isn't hooking cpu_physical_memory_{map,unmap}() not enough?  That's
> > really the intention of the API.
> >
> > You only really care about guest RAM, not device memory, correct?
> >      
> Yes, however at the moment all the calls to qemu_get_ram_ptr imply the
> mapping in qemu address space to remain valid for an unlimited amount of
> time.
>    
Yes, but qemu_get_ram_ptr() is not a general purpose API.  It really 
should only have one use--within exec.c to implement 
cpu_physical_memory_* functions.  There are a few uses in hw/* but 
they're all wrong and should be removed.  Fortunately, for the purposes 
of the Xen machine, almost none of them actually matter.
What I'm thinking is that RAM in Xen should not be backed at all from a 
RAMBlock.  Instead, cpu_physical_memory_* functions should call an 
explicit map/unmap() function that can be implemented as 
qemu_get_ram_ptr() and a nop in the TCG/KVM case and as explicit map 
cache operations in the Xen case.
Regards,

Anthony Liguori

> While we can do that because now the mapcache allows to "lock" a
> mapping, it would be nice if an explicit qemu_ram_ptr_unlock would be
> provided. It is not required for xen support though.
>
>
>    
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel