[Qemu-devel] Re: [PATCH 10/10] introduce qemu_ram_map

[Cam Macdonell <cam@cs.ualberta.ca>]

On Mon, Apr 26, 2010 at 11:59 AM, Marcelo Tosatti <mtosatti@redhat.com> wrote:
> Which allows drivers to register an mmaped region into ram block mappings.
> To be used by device assignment driver.
>
> CC: Cam Macdonell <cam@cs.ualberta.ca>
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> ---
>  cpu-common.h |    1 +
>  exec.c       |   28 ++++++++++++++++++++++++++++
>  2 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/cpu-common.h b/cpu-common.h
> index b24cecc..2dfde6f 100644
> --- a/cpu-common.h
> +++ b/cpu-common.h
> @@ -40,6 +40,7 @@ static inline void cpu_register_physical_memory(target_phys_addr_t start_addr,
>  }
>
>  ram_addr_t cpu_get_physical_page_desc(target_phys_addr_t addr);
> +ram_addr_t qemu_ram_map(ram_addr_t size, void *host);
>  ram_addr_t qemu_ram_alloc(ram_addr_t);
>  void qemu_ram_free(ram_addr_t addr);
>  /* This should only be used for ram local to a device.  */
> diff --git a/exec.c b/exec.c
> index 14d1fd7..648a9c9 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2789,6 +2789,34 @@ static void *file_ram_alloc(ram_addr_t memory, const char *path)
>  }
>  #endif
>
> +ram_addr_t qemu_ram_map(ram_addr_t size, void *host)
> +{
> +    RAMBlock *new_block;
> +
> +    size = TARGET_PAGE_ALIGN(size);
> +    new_block = qemu_malloc(sizeof(*new_block));
> +
> +    new_block->host = host;
> +
> +    new_block->offset = last_ram_offset;
> +    new_block->length = size;
> +
> +    new_block->next = ram_blocks;
> +    ram_blocks = new_block;
> +
> +    phys_ram_dirty = qemu_realloc(phys_ram_dirty,
> +        (last_ram_offset + size) >> TARGET_PAGE_BITS);
> +    memset(phys_ram_dirty + (last_ram_offset >> TARGET_PAGE_BITS),
> +           0xff, size >> TARGET_PAGE_BITS);
> +
> +    last_ram_offset += size;
> +
> +    if (kvm_enabled())
> +        kvm_setup_guest_memory(new_block->host, size);
> +
> +    return new_block->offset;
> +}
> +
>  ram_addr_t qemu_ram_alloc(ram_addr_t size)
>  {
>     RAMBlock *new_block;
> --
> 1.6.6.1
>

Sorry for being late to reply, is there a strong reason not to have
the function handle the mmap itself?  As As Anthony points out, that
way we don't have worry about realloc changing the pointer in the
function.