qemu-kvm.git uq/master queue

This is now done via the initialization's qemu_system_reset call.

Signed-off-by Avi Kivity<[email protected]>

---
  kvm-all.c |    1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

kvm-all.c +0 -0

index 9c8aa7d..eabb097 100644

Quoted 7 lines · Marcelo Tosatti

This is now done via the initialization's qemu_system_reset call.

Signed-off-by Avi Kivity<[email protected]>

---
 kvm-all.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

kvm-all.c int kvm_init_vcpu(CPUState *env) · line 213

Quoted 12 lines

kvm-all.c +0 -1

index 9c8aa7d..eabb097 100644
@@ -208,7 +208,6 @@ int kvm_init_vcpu(CPUState *env)
     ret = kvm_arch_init_vcpu(env);
     if (ret == 0) {
         qemu_register_reset(kvm_reset_vcpu, env);
-        kvm_arch_reset_vcpu(env);
     }
 err:
     return ret;

This breaks -enable-kvm in upstream qemu. No progress is ever made in the guest.

Quoted 9 lines · Anthony Liguori

Quoted 7 lines · Marcelo Tosatti

This is now done via the initialization's qemu_system_reset call.

Signed-off-by Avi Kivity<[email protected]>

---
  kvm-all.c |    1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

Quoted 16 lines

kvm-all.c int kvm_init_vcpu(CPUState *env) · line 213

Quoted 13 lines

kvm-all.c +0 -1

index 9c8aa7d..eabb097 100644
@@ -208,7 +208,6 @@ int kvm_init_vcpu(CPUState *env)
      ret = kvm_arch_init_vcpu(env);
      if (ret == 0) {
          qemu_register_reset(kvm_reset_vcpu, env);
-        kvm_arch_reset_vcpu(env);
      }
  err:
      return ret;

This breaks -enable-kvm in upstream qemu. No progress is ever made in the guest.

These patches have been autotested, and just confirmed manually that this patch does not break -enable-kvm (as the reset handler is now called through the notifier).

What is your qemu command line?

Quoted 8 lines · Anthony Liguori

Quoted 7 lines · Marcelo Tosatti

This is now done via the initialization's qemu_system_reset call.

Signed-off-by Avi Kivity<[email protected]>

---
 kvm-all.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

Quoted 15 lines

kvm-all.c int kvm_init_vcpu(CPUState *env) · line 213

Quoted 12 lines

kvm-all.c +0 -1

index 9c8aa7d..eabb097 100644
@@ -208,7 +208,6 @@ int kvm_init_vcpu(CPUState *env)
     ret = kvm_arch_init_vcpu(env);
     if (ret == 0) {
         qemu_register_reset(kvm_reset_vcpu, env);
-        kvm_arch_reset_vcpu(env);
     }
 err:
     return ret;

This breaks -enable-kvm in upstream qemu. No progress is ever made in the guest.

These patches have been autotested, and just confirmed manually that this patch does not break -enable-kvm (as the reset handler is now called through the notifier).

What is your qemu command line?

Which is significantly faster.

Signed-off-by Marcelo Tosatti <[email protected]>

---
 kvm-all.c |   53 +++++++++++++++++++++++++++++++++++++----------------

 1 files changed, 37 insertions(+), 16 deletions(-)

kvm-all.c +37 -17

index eabb097..ef45418 100644
@@ -26,6 +26,7 @@
  #include "hw/hw.h"
  #include "gdbstub.h"
  #include "kvm.h"
+#include "bswap.h"
 
  /* KVM uses PAGE_SIZE in it's definition of COALESCED_MMIO_MAX */
  #define PAGE_SIZE TARGET_PAGE_SIZE

@@ -282,11 +283,41 @@ static int kvm_set_migration_log(int enable)
     return 0;
  }
 
-static int test_le_bit(unsigned long nr, unsigned char *addr)
+/* get kvm's dirty pages bitmap and update qemu's */
+static int kvm_get_dirty_pages_log_range(unsigned long start_addr,
+                                         unsigned long *bitmap,
+                                         unsigned long offset,
+                                         unsigned long mem_size)
  {
-    return (addr[nr >> 3] >> (nr & 7)) & 1;
+    unsigned int i, j;
+    unsigned long page_number, addr, addr1, c;
+    ram_addr_t ram_addr;
+    unsigned int len = ((mem_size / TARGET_PAGE_SIZE) + HOST_LONG_BITS - 1) /
+        HOST_LONG_BITS;
+
+    /*
+     * bitmap-traveling is faster than memory-traveling (for addr...)
+     * especially when most of the memory is not dirty.
+     */
+    for (i = 0; i < len; i++) {
+        if (bitmap[i] != 0) {
+            c = leul_to_cpu(bitmap[i]);
+            do {
+                j = ffsl(c) - 1;
+                c &= ~(1ul << j);
+                page_number = i * HOST_LONG_BITS + j;
+                addr1 = page_number * TARGET_PAGE_SIZE;
+                addr = offset + addr1;
+                ram_addr = cpu_get_physical_page_desc(addr);
+                cpu_physical_memory_set_dirty(ram_addr);
+            } while (c != 0);
+        }
+    }
+    return 0;
  }
 
+#define ALIGN(x, y)  (((x)+(y)-1) & ~((y)-1))
+
  /**
  * kvm_physical_sync_dirty_bitmap - Grab dirty bitmap from kernel space
  * This function updates qemu's dirty bitmap using cpu_physical_memory_set_dirty().

@@ -300,8 +331,6 @@ static int kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
  {
     KVMState *s = kvm_state;
     unsigned long size, allocated_size = 0;
-    target_phys_addr_t phys_addr;
-    ram_addr_t addr;
     KVMDirtyLog d;
     KVMSlot *mem;
     int ret = 0;

@@ -313,7 +342,7 @@ static int kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
             break;
         }
 
-        size = ((mem->memory_size >> TARGET_PAGE_BITS) + 7) / 8;
+        size = ALIGN(((mem->memory_size) >> TARGET_PAGE_BITS), HOST_LONG_BITS) / 8;
         if (!d.dirty_bitmap) {
             d.dirty_bitmap = qemu_malloc(size);
         } else if (size > allocated_size) {

@@ -330,17 +359,9 @@ static int kvm_physical_sync_dirty_bitmap(target_phys_addr_t start_addr,
             break;
         }
 
-        for (phys_addr = mem->start_addr, addr = mem->phys_offset;
-             phys_addr < mem->start_addr + mem->memory_size;
-             phys_addr += TARGET_PAGE_SIZE, addr += TARGET_PAGE_SIZE) {
-            unsigned char *bitmap = (unsigned char *)d.dirty_bitmap;
-            unsigned nr = (phys_addr - mem->start_addr) >> TARGET_PAGE_BITS;
-
-            if (test_le_bit(nr, bitmap)) {
-                cpu_physical_memory_set_dirty(addr);
-            }
-        }
-        start_addr = phys_addr;
+        kvm_get_dirty_pages_log_range(mem->start_addr, d.dirty_bitmap,
+                                      mem->start_addr, mem->memory_size);
+        start_addr = mem->start_addr + mem->memory_size;
     }
     qemu_free(d.dirty_bitmap);
 
--

1.6.6.1

Hi,

This patch may conflict with the patch I posted on April 19.

http://www.mail-archive.com/[email protected]/msg29941.html

If Marcelo's is going to be merged, I need to rebase the above to it. It would be helpful if you could tell me the plan.

Thanks,

Yoshi

Quoted 9 lines · Yoshiaki Tamura

Hi,

This patch may conflict with the patch I posted on April 19.

http://www.mail-archive.com/[email protected]/msg29941.html

If Marcelo's is going to be merged, I need to rebase the above to it. It would be helpful if you could tell me the plan.

Quoted 3 lines

Thanks,

Yoshi

Yoshi,

Whatever gets in first, the other patch will have to rebased. I'm fine either way.

Which allows drivers to register an mmaped region into ram block mappings. To be used by device assignment driver.

CC Cam Macdonell<[email protected]>

Signed-off-by Marcelo Tosatti<[email protected]>

---
  cpu-common.h |    1 +
  exec.c       |   28 ++++++++++++++++++++++++++++
  2 files changed, 29 insertions(+), 0 deletions(-)

cpu-common.h +1 -0

index b24cecc..2dfde6f 100644
@@ -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.  */

exec.c +28 -0

index 14d1fd7..648a9c9 100644
@@ -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;

Quoted 2 lines · Marcelo Tosatti

Which allows drivers to register an mmaped region into ram block mappings. To be used by device assignment driver.

This doesn't make much sense to me.

Do you use this like:

qemu_ram_map(64k, ptr);
assert(qemu_ram_alloc(64k) == ptr);

If so, I think this is not the best API. I'd rather see qemu_ram_map() register a symbolic name for the region and for there to be a qemu_ram_alloc() variant that allocated by name.

Regards,

Anthony Liguori

Quoted 7 lines · Anthony Liguori

Quoted 3 lines · Marcelo Tosatti

Which allows drivers to register an mmaped region into ram block mappings. To be used by device assignment driver.

This doesn't make much sense to me.

Quoted 5 lines

Do you use this like:

qemu_ram_map(64k, ptr);
assert(qemu_ram_alloc(64k) == ptr);

No. hw/device-assignment.c in qemu-kvm mmaps /sys/bus/pci/devices/x:y:z/resourcen (the PCI devices memory regions) to the guest.

Quoted 9 lines

If so, I think this is not the best API. I'd rather see qemu_ram_map() register a symbolic name for the region and for there to be a qemu_ram_alloc() variant that allocated by name.

Regards,

Anthony Liguori

Quoted 16 lines · Marcelo Tosatti

Quoted 13 lines · Anthony Liguori

Quoted 5 lines · Marcelo Tosatti

Which allows drivers to register an mmaped region into ram block mappings.
To be used by device assignment driver.

This doesn't make much sense to me.

Do you use this like:

Quoted 8 lines

Quoted 3 lines

qemu_ram_map(64k, ptr);
assert(qemu_ram_alloc(64k) == ptr);

No. hw/device-assignment.c in qemu-kvm mmaps /sys/bus/pci/devices/x:y:z/resourcen (the PCI devices memory regions) to the guest.

I understand, but how do you use qemu_ram_map() to actually map that memory to a given PCI device resource?  I assume you rely on it getting put on the front of the list so that the next qemu_ram_alloc() will be at that location.

Regards,

Anthony Liguori

Quoted 9 lines

Quoted 9 lines

If so, I think this is not the best API.  I'd rather see qemu_ram_map() register a symbolic name for the region and for there to be a qemu_ram_alloc() variant that allocated by name.

Regards,

Anthony Liguori

Quoted 26 lines · Anthony Liguori

Quoted 16 lines · Marcelo Tosatti

Quoted 13 lines · Anthony Liguori

Quoted 5 lines · Marcelo Tosatti

Which allows drivers to register an mmaped region into ram block mappings.
To be used by device assignment driver.

This doesn't make much sense to me.

Do you use this like:

Quoted 8 lines

Quoted 3 lines

qemu_ram_map(64k, ptr);
assert(qemu_ram_alloc(64k) == ptr);

No. hw/device-assignment.c in qemu-kvm mmaps /sys/bus/pci/devices/x:y:z/resourcen (the PCI devices memory regions) to the guest.

Quoted 4 lines

I understand, but how do you use qemu_ram_map() to actually map that memory to a given PCI device resource?  I assume you rely on it getting put on the front of the list so that the next qemu_ram_alloc() will be at that location.

In my shared memory patch, I passed the offset returned from qemu_ram_mmap to cpu_register_physical_memory from within the map function passed to pci_register_bar. Could the same not be done? Is there something incorrect with this approach?

Which allows drivers to register an mmaped region into ram block mappings. To be used by device assignment driver.

CC Cam Macdonell<[email protected]>

Signed-off-by Marcelo Tosatti<[email protected]>

---
  cpu-common.h |    1 +
  exec.c       |   28 ++++++++++++++++++++++++++++
  2 files changed, 29 insertions(+), 0 deletions(-)

cpu-common.h +1 -0

index b24cecc..2dfde6f 100644
@@ -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.  */

exec.c +28 -0

index 14d1fd7..648a9c9 100644
@@ -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;

Quoted 3 lines · Marcelo Tosatti

Which allows drivers to register an mmaped region into ram block mappings. To be used by device assignment driver.

This is not kvm specific and not required by this pull request so it shouldn't really be part of the pull. Something like this should only be added when there's an actual consumer.

Quoted 6 lines · Anthony Liguori

Quoted 4 lines · Marcelo Tosatti

Which allows drivers to register an mmaped region into ram block mappings. To be used by device assignment driver.

Quoted 4 lines

This is not kvm specific and not required by this pull request so it shouldn't really be part of the pull. Something like this should only be added when there's an actual consumer.

The user will be hw/device-assignment.c in qemu-kvm. And also Cam has the need for a similar interface for shared memory drivers.

Index: qemu-kvm/hw/device-assignment.c
===================================================================

hw/device-assignment.c +17 -19

@@ -256,10 +256,7 @@
      AssignedDevice *r_dev = container_of(pci_dev, AssignedDevice, dev);
      AssignedDevRegion *region =&r_dev->v_addrs[region_num];
      PCIRegion *real_region =&r_dev->real_device.regions[region_num];
-    pcibus_t old_ephys = region->e_physbase;
-    pcibus_t old_esize = region->e_size;
-    int first_map = (region->e_size == 0);
-    int ret = 0;
+    int ret = 0, flags = 0;
 
      DEBUG("e_phys=%08" FMT_PCIBUS " r_virt=%p type=%d len=%08" FMT_PCIBUS " region_num=%d \n",
            e_phys, region->u.r_virtbase, type, e_size, region_num);

@@ -267,30 +264,22 @@
      region->e_physbase = e_phys;
      region->e_size = e_size;
 
-    if (!first_map)
-	kvm_destroy_phys_mem(kvm_context, old_ephys,
-                             TARGET_PAGE_ALIGN(old_esize));
-
      if (e_size>  0) {
+
+        if (region_num == PCI_ROM_SLOT)
+            flags |= IO_MEM_ROM;
+
+        cpu_register_physical_memory(e_phys, e_size, region->memory_index | flags);
+
          /* deal with MSI-X MMIO page */
          if (real_region->base_addr<= r_dev->msix_table_addr&&
                  real_region->base_addr + real_region->size>=
                  r_dev->msix_table_addr) {
              int offset = r_dev->msix_table_addr - real_region->base_addr;
-            ret = munmap(region->u.r_virtbase + offset, TARGET_PAGE_SIZE);
-            if (ret == 0)
-                DEBUG("munmap done, virt_base 0x%p\n",
-                        region->u.r_virtbase + offset);
-            else {
-                fprintf(stderr, "%s: fail munmap msix table!\n", __func__);
-                exit(1);
-            }
+
              cpu_register_physical_memory(e_phys + offset,
                      TARGET_PAGE_SIZE, r_dev->mmio_index);
          }
-	ret = kvm_register_phys_mem(kvm_context, e_phys,
-                                    region->u.r_virtbase,
-                                    TARGET_PAGE_ALIGN(e_size), 0);
      }
 
      if (ret != 0) {

@@ -539,6 +528,15 @@
              pci_dev->v_addrs[i].u.r_virtbase +=
                  (cur_region->base_addr&  0xFFF);
 
+
+            if (!slow_map) {
+                void *virtbase = pci_dev->v_addrs[i].u.r_virtbase;
+
+                pci_dev->v_addrs[i].memory_index = qemu_ram_map(cur_region->size,
+                                                                virtbase);
+            } else
+                pci_dev->v_addrs[i].memory_index = 0;
+
              pci_register_bar((PCIDevice *) pci_dev, i,
                               cur_region->size, t,
                               slow_map ? assigned_dev_iomem_map_slow

Index: qemu-kvm/hw/device-assignment.h
===================================================================

hw/device-assignment.h +1 -1

@@ -63,7 +63,7 @@
 
  typedef struct {
      pcibus_t e_physbase;
-    uint32_t memory_index;
+    ram_addr_t memory_index;
      union {
          void *r_virtbase;    /* mmapped access address for memory regions */
          uint32_t r_baseport; /* the base guest port for I/O regions */

Quoted 5 lines · Marcelo Tosatti

Quoted 4 lines · Anthony Liguori

Quoted 3 lines · Marcelo Tosatti

Which allows drivers to register an mmaped region into ram block mappings. To be used by device assignment driver.

Quoted 5 lines

Quoted 3 lines

This is not kvm specific and not required by this pull request so it shouldn't really be part of the pull. Something like this should only be added when there's an actual consumer.

The user will be hw/device-assignment.c in qemu-kvm. And also Cam has the need for a similar interface for shared memory drivers.

It should be part of one of those submissions.

Quoted 5 lines

hw/device-assignment.c +0 -1

@@ -726,10 +724,6 @@
                 kvm_remove_ioperm_data(region->u.r_baseport, region->r_size);
                 continue;
             } else if (pci_region->type&  IORESOURCE_MEM) {
-                if (region->e_size>  0)

hw/device-assignment.c

Quoted 6 lines

hw/device-assignment.c +0 -3

-                    kvm_destroy_phys_mem(kvm_context, region->e_physbase,
-                                         TARGET_PAGE_ALIGN(region->e_size));
-
                 if (region->u.r_virtbase) {
                     int ret = munmap(region->u.r_virtbase,
                                      (pci_region->size + 0xFFF)&  0xFFFFF000);

How does hot unplug get dealt with?

Quoted 10 lines · Anthony Liguori

Quoted 8 lines · Marcelo Tosatti

Quoted 6 lines · Anthony Liguori

Quoted 4 lines · Marcelo Tosatti

Which allows drivers to register an mmaped region into ram block mappings. To be used by device assignment driver.

Quoted 9 lines

Quoted 7 lines

Quoted 4 lines

This is not kvm specific and not required by this pull request so it shouldn't really be part of the pull. Something like this should only be added when there's an actual consumer.

The user will be hw/device-assignment.c in qemu-kvm. And also Cam has the need for a similar interface for shared memory drivers.

It should be part of one of those submissions.

OK

Quoted 5 lines

Quoted 5 lines

hw/device-assignment.c +0 -1

@@ -726,10 +724,6 @@
                  kvm_remove_ioperm_data(region->u.r_baseport, region->r_size);
                  continue;
              } else if (pci_region->type&   IORESOURCE_MEM) {
-                if (region->e_size>   0)

Quoted 9 lines

hw/device-assignment.c

Quoted 7 lines

hw/device-assignment.c +0 -3

-                    kvm_destroy_phys_mem(kvm_context, region->e_physbase,
-                                         TARGET_PAGE_ALIGN(region->e_size));
-
                  if (region->u.r_virtbase) {
                      int ret = munmap(region->u.r_virtbase,
                                       (pci_region->size + 0xFFF)&   0xFFFFF000);

How does hot unplug get dealt with?

The regions will have such mappings unmapped from QEMU (and KVM) via cpu_register_physical_memory(IO_MEM_UNASSIGNED) via pci_unregister_io_regions.

Just pushed a new tree without the patch, please pull if you are OK with the other changes.

Quoted 27 lines · Marcelo Tosatti

Quoted 6 lines · Anthony Liguori

Quoted 5 lines · Marcelo Tosatti

Quoted 4 lines · Anthony Liguori

Quoted 3 lines · Marcelo Tosatti

Which allows drivers to register an mmaped region into ram block mappings. To be used by device assignment driver.

Quoted 6 lines

Quoted 5 lines

Quoted 3 lines

This is not kvm specific and not required by this pull request so it shouldn't really be part of the pull. Something like this should only be added when there's an actual consumer.

The user will be hw/device-assignment.c in qemu-kvm. And also Cam has the need for a similar interface for shared memory drivers.

It should be part of one of those submissions.

OK

Quoted 12 lines

hw/device-assignment.c line 729

Quoted 11 lines

hw/device-assignment.c +0 -4

@@ -726,10 +724,6 @@
                 kvm_remove_ioperm_data(region->u.r_baseport, region->r_size);
                 continue;
             } else if (pci_region->type&   IORESOURCE_MEM) {
-                if (region->e_size>   0)
-                    kvm_destroy_phys_mem(kvm_context, region->e_physbase,
-                                         TARGET_PAGE_ALIGN(region->e_size));
-
                 if (region->u.r_virtbase) {
                     int ret = munmap(region->u.r_virtbase,
                                      (pci_region->size + 0xFFF)&   0xFFFFF000);

How does hot unplug get dealt with?

Quoted 3 lines

The regions will have such mappings unmapped from QEMU (and KVM) via cpu_register_physical_memory(IO_MEM_UNASSIGNED) via pci_unregister_io_regions.

But how do you qemu_ram_unmap()? I see you munmap() that address but it looks like the qemu ram region gets leaked pointing to an invalid pointer.

Which allows drivers to register an mmaped region into ram block mappings. To be used by device assignment driver.

CC Cam Macdonell <[email protected]>

Signed-off-by Marcelo Tosatti <[email protected]>

---
 cpu-common.h |    1 +
 exec.c       |   28 ++++++++++++++++++++++++++++

 2 files changed, 29 insertions(+), 0 deletions(-)

cpu-common.h +1 -0

index b24cecc..2dfde6f 100644
@@ -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.  */

exec.c +28 -1

index 14d1fd7..648a9c9 100644
@@ -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

Quoted 32 lines

exec.c +28 -0

+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;

Quoted 3 lines

--
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.

The following changes since commit a303f9e37b87ced34e966dc2c0b7f86bc5e74035:
Blue Swirl (1):
sh4: remove dead assignments, spotted by clang analyzer

are available in the git repository at:

git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master

Jan Kiszka (1):
KVM: x86: Add debug register saving and restoring

Marcelo Tosatti (8):
target-i386: print EFER in cpu_dump_state
kvm: handle internal error
kvm_init_vcpu requires global lock held
kvm: remove explicit kvm_arch_reset_vcpu from kvm_init_vcpu
vga: fix typo in length passed to kvm_log_stop introduce leul_to_cpu
kvm: port qemu-kvm's bitmap scanning
introduce qemu_ram_map

Sheng Yang (1):
kvm: allow qemu to set EPT identity mapping address

  bswap.h              |    2 +
  cpu-common.h         |    1 +
  cpus.c               |    2 +-
  exec.c               |   28 ++++++++++++++
  hw/vga.c             |    4 +-
  kvm-all.c            |   96 +++++++++++++++++++++++++++++++++++++++++---------
  kvm.h                |    1 +
  target-i386/helper.c |    1 +
  target-i386/kvm.c    |   81 +++++++++++++++++++++++++++++++++++++++++-
  9 files changed, 195 insertions(+), 21 deletions(-)