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

[Xen-devel] Re: [Qemu-devel] [PATCH RFC V3 08/12] Intruduce qemu_ram_ptr_unlock.


  • To: anthony.perard@xxxxxxxxxx
  • From: Blue Swirl <blauwirbel@xxxxxxxxx>
  • Date: Fri, 17 Sep 2010 19:42:02 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, qemu-devel@xxxxxxxxxx, Stefano.Stabellini@xxxxxxxxxxxxx
  • Delivery-date: Fri, 17 Sep 2010 12:43:11 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=nsYeskrXHlOAjUa057dWH3tkIHPmkdxghJ10N38zLBrpn/ITApyTnTEYE/1JFy6hG3 0FDMFtpsZTiOj06OzYkXboMnJcuEw+HZf0pKXbfcJ/Lk6qZZvze0PbOTuimbch9uWi8H 7boykgWwssDgf1voqqddcTQ89VZn2jW/uEJ7A=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Fri, Sep 17, 2010 at 11:15 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>
> ---
> Âcpu-common.h  |  Â1 +
> Âexec.c     |  29 ++++++++++++++++++++++++++---
> Âxen_mapcache.c | Â 34 ++++++++++++++++++++++++++++++++++
> Âxen_mapcache.h | Â Â1 +
> Â4 files changed, 62 insertions(+), 3 deletions(-)
>
> diff --git a/cpu-common.h b/cpu-common.h
> index 0426bc8..378eea8 100644
> --- a/cpu-common.h
> +++ b/cpu-common.h
> @@ -46,6 +46,7 @@ ram_addr_t qemu_ram_alloc(DeviceState *dev, const char 
> *name, ram_addr_t size);
> Âvoid qemu_ram_free(ram_addr_t addr);
> Â/* This should only be used for ram local to a device. Â*/
> Âvoid *qemu_get_ram_ptr(ram_addr_t addr);
> +void qemu_ram_ptr_unlock(void *addr);
> Â/* This should not be used by devices. Â*/
> Âram_addr_t qemu_ram_addr_from_host(void *ptr);
>
> diff --git a/exec.c b/exec.c
> index f5888eb..659db50 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2959,6 +2959,13 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
> Â Â return NULL;
> Â}
>
> +void qemu_ram_ptr_unlock(void *addr)
> +{
> + Â Âif (xen_enabled()) {
> + Â Â Â Âqemu_map_cache_unlock(addr);

I think there may be linkage problems without CONFIG_XEN, so there
should be a stub for qemu_map_cache_unlock().

> + Â Â}
> +}
> +
> Â/* Some of the softmmu routines need to translate from a host pointer
> Â Â(typically a TLB entry) back to a ram offset. Â*/
> Âram_addr_t qemu_ram_addr_from_host(void *ptr)
> @@ -3064,6 +3071,7 @@ static void notdirty_mem_writeb(void *opaque, 
> target_phys_addr_t ram_addr,
> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â uint32_t val)
> Â{
> Â Â int dirty_flags;
> + Â Âvoid *vaddr;
> Â Â dirty_flags = cpu_physical_memory_get_dirty_flags(ram_addr);
> Â Â if (!(dirty_flags & CODE_DIRTY_FLAG)) {
> Â#if !defined(CONFIG_USER_ONLY)
> @@ -3071,19 +3079,21 @@ static void notdirty_mem_writeb(void *opaque, 
> target_phys_addr_t ram_addr,
> Â Â Â Â dirty_flags = cpu_physical_memory_get_dirty_flags(ram_addr);
> Â#endif
> Â Â }
> - Â Âstb_p(qemu_get_ram_ptr(ram_addr), val);
> + Â Âstb_p(vaddr = qemu_get_ram_ptr(ram_addr), val);

Perhaps 'vaddr = ...'  should be put on a separate line.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.