[Qemu-devel] [PULL 0/5] QMP queue

[Qemu-devel] [PULL 0/5] QMP queue

[Luiz Capitulino]

Hi,

This pull request contains two series. A balloon series and memory hotplug
doc series. The balloon series is not totally QMP related, but it has
implications to libvirt when using memory hotplug. So, I'm picking it up.
The second series is a memory hotplug doc improvement. This is not QMP
related at all, but I'm adding it here as it got fully reviewed and is
really wanted.

The following changes since commit 3539bbb93e944ffde31c61c369ea9eedcc5697a6:

  Merge remote-tracking branch 'remotes/awilliam/tags/vfio-update-20150302.0' into staging (2015-03-04 14:37:31 +0000)

are available in the git repository at:


  git://repo.or.cz/qemu/qmp-unstable.git queue/qmp

for you to fetch changes up to a3b042179859c68b3d08f8aa43866d28d6b56987:

  docs: add memory-hotplug.txt (2015-03-04 13:00:36 -0500)

----------------------------------------------------------------
Luiz Capitulino (2):
      qemu-options.hx: improve -m description
      docs: add memory-hotplug.txt

zhanghailiang (3):
      pc-dimm: add a function to calculate VM's current RAM size
      virtio-balloon: Fix balloon not working correctly when hotplug memory
      virtio-balloon: Add some trace events

 docs/memory-hotplug.txt         | 76 +++++++++++++++++++++++++++++++++++++++++
 hw/mem/pc-dimm.c                | 26 ++++++++++++++
 hw/virtio/virtio-balloon.c      | 21 ++++++++----
 include/exec/cpu-common.h       |  1 +
 qemu-options.hx                 | 22 +++++++++---
 stubs/qmp_pc_dimm_device_list.c |  5 +++
 trace-events                    |  4 +++
 7 files changed, 144 insertions(+), 11 deletions(-)
 create mode 100644 docs/memory-hotplug.txt

[Qemu-devel] [PULL 1/5] pc-dimm: add a function to calculate VM's current RAM size

[Luiz Capitulino]

From: zhanghailiang <zhang.zhanghailiang@huawei.com>

The global parameter 'ram_size' does not take into account
the hotplugged memory.

In some codes, we use 'ram_size' as current VM's real RAM size,
which is not correct.

Add function 'get_current_ram_size' to calculate VM's current RAM size,
it will enumerate present memory devices and also plus ram_size.

Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 hw/mem/pc-dimm.c                | 26 ++++++++++++++++++++++++++
 include/exec/cpu-common.h       |  1 +
 stubs/qmp_pc_dimm_device_list.c |  5 +++++
 3 files changed, 32 insertions(+)

diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index f27a087..de81b9c 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -100,6 +100,32 @@ int qmp_pc_dimm_device_list(Object *obj, void *opaque)
     return 0;
 }
 
+ram_addr_t get_current_ram_size(void)
+{
+    MemoryDeviceInfoList *info_list = NULL;
+    MemoryDeviceInfoList **prev = &info_list;
+    MemoryDeviceInfoList *info;
+    ram_addr_t size = ram_size;
+
+    qmp_pc_dimm_device_list(qdev_get_machine(), &prev);
+    for (info = info_list; info; info = info->next) {
+        MemoryDeviceInfo *value = info->value;
+
+        if (value) {
+            switch (value->kind) {
+            case MEMORY_DEVICE_INFO_KIND_DIMM:
+                size += value->dimm->size;
+                break;
+            default:
+                break;
+            }
+        }
+    }
+    qapi_free_MemoryDeviceInfoList(info_list);
+
+    return size;
+}
+
 static int pc_dimm_slot2bitmap(Object *obj, void *opaque)
 {
     unsigned long *bitmap = opaque;
diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 427b851..fcc3162 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -52,6 +52,7 @@ typedef uintptr_t ram_addr_t;
 #endif
 
 extern ram_addr_t ram_size;
+ram_addr_t get_current_ram_size(void);
 
 /* memory API */
 
diff --git a/stubs/qmp_pc_dimm_device_list.c b/stubs/qmp_pc_dimm_device_list.c
index 5cb220c..b584bd8 100644
--- a/stubs/qmp_pc_dimm_device_list.c
+++ b/stubs/qmp_pc_dimm_device_list.c
@@ -5,3 +5,8 @@ int qmp_pc_dimm_device_list(Object *obj, void *opaque)
 {
    return 0;
 }
+
+ram_addr_t get_current_ram_size(void)
+{
+    return ram_size;
+}
-- 
1.9.3

[Qemu-devel] [PULL 2/5] virtio-balloon: Fix balloon not working correctly when hotplug memory

[Luiz Capitulino]

From: zhanghailiang <zhang.zhanghailiang@huawei.com>

When do memory balloon, it takes the 'ram_size' as the VM's current ram size,
But 'ram_size' is the startup configured ram size, it does not take into
account the hotplugged memory.

As a result, the balloon result will be confused.
Steps to reproduce:
(1)Start VM: qemu -m size=1024,slots=4,maxmem=8G
(2)In VM: #free -m : 1024M
(3)qmp balloon 512M
(4)In VM: #free -m : 512M
(5)hotplug pc-dimm 1G
(6)In VM: #free -m : 1512M
(7)qmp balloon 256M
(8)In VM: #free -m :1256M
We expect the VM's available ram size to be 256M after 'qmp balloon 256M'
command, but VM's real available ram size is 1256M.

For "qmp balloon" is not performance critical code, we use function
'get_current_ram_size' to get VM's current ram size.

Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 hw/virtio/virtio-balloon.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 7bfbb75..41b24c9 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -294,10 +294,12 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
     VirtIOBalloon *dev = VIRTIO_BALLOON(vdev);
     struct virtio_balloon_config config;
     uint32_t oldactual = dev->actual;
+    ram_addr_t vm_ram_size = get_current_ram_size();
+
     memcpy(&config, config_data, sizeof(struct virtio_balloon_config));
     dev->actual = le32_to_cpu(config.actual);
     if (dev->actual != oldactual) {
-        qapi_event_send_balloon_change(ram_size -
+        qapi_event_send_balloon_change(vm_ram_size -
                         ((ram_addr_t) dev->actual << VIRTIO_BALLOON_PFN_SHIFT),
                         &error_abort);
     }
@@ -312,20 +314,21 @@ static uint32_t virtio_balloon_get_features(VirtIODevice *vdev, uint32_t f)
 static void virtio_balloon_stat(void *opaque, BalloonInfo *info)
 {
     VirtIOBalloon *dev = opaque;
-    info->actual = ram_size - ((uint64_t) dev->actual <<
-                               VIRTIO_BALLOON_PFN_SHIFT);
+    info->actual = get_current_ram_size() - ((uint64_t) dev->actual <<
+                                             VIRTIO_BALLOON_PFN_SHIFT);
 }
 
 static void virtio_balloon_to_target(void *opaque, ram_addr_t target)
 {
     VirtIOBalloon *dev = VIRTIO_BALLOON(opaque);
     VirtIODevice *vdev = VIRTIO_DEVICE(dev);
+    ram_addr_t vm_ram_size = get_current_ram_size();
 
-    if (target > ram_size) {
-        target = ram_size;
+    if (target > vm_ram_size) {
+        target = vm_ram_size;
     }
     if (target) {
-        dev->num_pages = (ram_size - target) >> VIRTIO_BALLOON_PFN_SHIFT;
+        dev->num_pages = (vm_ram_size - target) >> VIRTIO_BALLOON_PFN_SHIFT;
         virtio_notify_config(vdev);
     }
 }
-- 
1.9.3

[Qemu-devel] [PULL 3/5] virtio-balloon: Add some trace events

[Luiz Capitulino]

From: zhanghailiang <zhang.zhanghailiang@huawei.com>

Add some trace events for easier debugging

Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
---
 hw/virtio/virtio-balloon.c | 6 ++++++
 trace-events               | 4 ++++
 2 files changed, 10 insertions(+)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 41b24c9..8a48d2a 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -25,6 +25,7 @@
 #include "exec/address-spaces.h"
 #include "qapi/visitor.h"
 #include "qapi-event.h"
+#include "trace.h"
 
 #if defined(__linux__)
 #include <sys/mman.h>
@@ -222,6 +223,8 @@ static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
             if (!int128_nz(section.size) || !memory_region_is_ram(section.mr))
                 continue;
 
+            trace_virtio_balloon_handle_output(memory_region_name(section.mr),
+                                               pa);
             /* Using memory_region_get_ram_ptr is bending the rules a bit, but
                should be OK because we only want a single page.  */
             addr = section.offset_within_region;
@@ -285,6 +288,7 @@ static void virtio_balloon_get_config(VirtIODevice *vdev, uint8_t *config_data)
     config.num_pages = cpu_to_le32(dev->num_pages);
     config.actual = cpu_to_le32(dev->actual);
 
+    trace_virtio_balloon_get_config(config.num_pages, config.actual);
     memcpy(config_data, &config, sizeof(struct virtio_balloon_config));
 }
 
@@ -303,6 +307,7 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
                         ((ram_addr_t) dev->actual << VIRTIO_BALLOON_PFN_SHIFT),
                         &error_abort);
     }
+    trace_virtio_balloon_set_config(dev->actual, oldactual);
 }
 
 static uint32_t virtio_balloon_get_features(VirtIODevice *vdev, uint32_t f)
@@ -331,6 +336,7 @@ static void virtio_balloon_to_target(void *opaque, ram_addr_t target)
         dev->num_pages = (vm_ram_size - target) >> VIRTIO_BALLOON_PFN_SHIFT;
         virtio_notify_config(vdev);
     }
+    trace_virtio_balloon_to_target(target, dev->num_pages);
 }
 
 static void virtio_balloon_save(QEMUFile *f, void *opaque)
diff --git a/trace-events b/trace-events
index f87b077..65385f6 100644
--- a/trace-events
+++ b/trace-events
@@ -143,6 +143,10 @@ cpu_out(unsigned int addr, unsigned int val) "addr %#x value %u"
 # balloon.c
 # Since requests are raised via monitor, not many tracepoints are needed.
 balloon_event(void *opaque, unsigned long addr) "opaque %p addr %lu"
+virtio_balloon_handle_output(const char *name, uint64_t gpa) "setion name: %s gpa: %"PRIx64""
+virtio_balloon_get_config(uint32_t num_pages, uint32_t acutal) "num_pages: %d acutal: %d"
+virtio_balloon_set_config(uint32_t acutal, uint32_t oldacutal) "acutal: %d oldacutal: %d"
+virtio_balloon_to_target(uint64_t target, uint32_t num_pages) "balloon target: %"PRIx64" num_pages: %d"
 
 # hw/intc/apic_common.c
 cpu_set_apic_base(uint64_t val) "%016"PRIx64
-- 
1.9.3

[Qemu-devel] [PULL 4/5] qemu-options.hx: improve -m description

[Luiz Capitulino]

Add memory hotplug options to the command-line format. Also,
add a complete command-line example and improve description.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Paulo Vital <paulo.vital@profitbricks.com>
---
 qemu-options.hx | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index 85ca3ad..b0345ae 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -237,12 +237,24 @@ DEF("m", HAS_ARG, QEMU_OPTION_m,
     "NOTE: Some architectures might enforce a specific granularity\n",
     QEMU_ARCH_ALL)
 STEXI
-@item -m [size=]@var{megs}
+@item -m [size=]@var{megs}[,slots=n,maxmem=size]
 @findex -m
-Set virtual RAM size to @var{megs} megabytes. Default is 128 MiB.  Optionally,
-a suffix of ``M'' or ``G'' can be used to signify a value in megabytes or
-gigabytes respectively. Optional pair @var{slots}, @var{maxmem} could be used
-to set amount of hotluggable memory slots and possible maximum amount of memory.
+Sets guest startup RAM size to @var{megs} megabytes. Default is 128 MiB.
+Optionally, a suffix of ``M'' or ``G'' can be used to signify a value in
+megabytes or gigabytes respectively. Optional pair @var{slots}, @var{maxmem}
+could be used to set amount of hotpluggable memory slots and maximum amount of
+memory. Note that @var{maxmem} must be aligned to the page size.
+
+For example, the following command-line sets the guest startup RAM size to
+1GB, creates 3 slots to hotplug additional memory and sets the maximum
+memory the guest can reach to 4GB:
+
+@example
+qemu-system-x86_64 -m 1G,slots=3,maxmem=4G
+@end example
+
+If @var{slots} and @var{maxmem} are not specified, memory hotplug won't
+be enabled and the guest startup RAM will never increase.
 ETEXI
 
 DEF("mem-path", HAS_ARG, QEMU_OPTION_mempath,
-- 
1.9.3

[Qemu-devel] [PULL 5/5] docs: add memory-hotplug.txt

[Luiz Capitulino]

This document describes how to use memory hotplug in QEMU.

Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Paulo Vital <paulo.vital@profitbricks.com>
---
 docs/memory-hotplug.txt | 76 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 docs/memory-hotplug.txt

diff --git a/docs/memory-hotplug.txt b/docs/memory-hotplug.txt
new file mode 100644
index 0000000..f70571d
--- /dev/null
+++ b/docs/memory-hotplug.txt
@@ -0,0 +1,76 @@
+QEMU memory hotplug
+===================
+
+This document explains how to use the memory hotplug feature in QEMU,
+which is present since v2.1.0.
+
+Please, note that memory hotunplug is not supported yet. This means
+that you're able to add memory, but you're not able to remove it.
+Also, proper guest support is required for memory hotplug to work.
+
+Basic RAM hotplug
+-----------------
+
+In order to be able to hotplug memory, QEMU has to be told how many
+hotpluggable memory slots to create and what is the maximum amount of
+memory the guest can grow. This is done at startup time by means of
+the -m command-line option, which has the following format:
+
+ -m [size=]megs[,slots=n,maxmem=size]
+
+Where,
+
+ - "megs" is the startup RAM. It is the RAM the guest will boot with
+ - "slots" is the number of hotpluggable memory slots
+ - "maxmem" is the maximum RAM size the guest can have
+
+For example, the following command-line:
+
+ qemu [...] 1G,slots=3,maxmem=4G
+
+Creates a guest with 1GB of memory and three hotpluggable memory slots.
+The hotpluggable memory slots are empty when the guest is booted, so all
+memory the guest will see after boot is 1GB. The maximum memory the
+guest can reach is 4GB. This means that three additional gigabytes can be
+hotplugged by using any combination of the available memory slots.
+
+Two monitor commands are used to hotplug memory:
+
+ - "object_add": creates a memory backend object
+ - "device_add": creates a front-end pc-dimm device and inserts it
+                 into the first empty slot
+
+For example, the following commands add another 1GB to the guest
+discussed earlier:
+
+  (qemu) object_add memory-backend-ram,id=mem1,size=1G
+  (qemu) device_add pc-dimm,id=dimm1,memdev=mem1
+
+Using the file backend
+----------------------
+
+Besides basic RAM hotplug, QEMU also supports using files as a memory
+backend. This is useful for using hugetlbfs in Linux, which provides
+access to bigger page sizes.
+
+For example, assuming that the host has 1GB hugepages available in
+the /mnt/hugepages-1GB directory, a 1GB hugepage could be hotplugged
+into the guest from the previous section with the following commands:
+
+  (qemu) object_add memory-backend-file,id=mem1,size=1G,mem-path=/mnt/hugepages-1GB
+  (qemu) device_add pc-dimm,id=dimm1,memdev=mem1
+
+It's also possible to start a guest with memory cold-plugged into the
+hotpluggable memory slots. This might seem counterintuitive at first,
+but this allows for a lot of flexibility when using the file backend.
+
+In the following command-line example, a 8GB guest is created where 6GB
+comes from regular RAM, 1GB is a 1GB hugepage page and 256MB is from
+2MB pages. Also, the guest has additional memory slots to hotplug more
+2GB if needed:
+
+ qemu [...] -m 6GB,slots=4,maxmem=10G \
+   -object memory-backend-file,id=mem1,size=1G,mem-path=/mnt/hugepages-1G \
+   -device pc-dimm,id=dimm1,memdev=mem1 \
+   -object memory-backend-file,id=mem2,size=256M,mem-path=/mnt/hugepages-2MB \
+   -device pc-dimm,id=dimm2,memdev=mem2
-- 
1.9.3

Re: [Qemu-devel] [PULL 0/5] QMP queue

[Peter Maydell]

On 5 March 2015 at 04:13, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> Hi,
>
> This pull request contains two series. A balloon series and memory hotplug
> doc series. The balloon series is not totally QMP related, but it has
> implications to libvirt when using memory hotplug. So, I'm picking it up.
> The second series is a memory hotplug doc improvement. This is not QMP
> related at all, but I'm adding it here as it got fully reviewed and is
> really wanted.
>
> The following changes since commit 3539bbb93e944ffde31c61c369ea9eedcc5697a6:
>
>   Merge remote-tracking branch 'remotes/awilliam/tags/vfio-update-20150302.0' into staging (2015-03-04 14:37:31 +0000)
>
> are available in the git repository at:
>
>
>   git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
>
> for you to fetch changes up to a3b042179859c68b3d08f8aa43866d28d6b56987:
>
>   docs: add memory-hotplug.txt (2015-03-04 13:00:36 -0500)

Nudge: this isn't a signed pull request. I'm not currently rejecting
unsigned pulls, but at some point in the not very distant future
(maybe after 2.3?) I plan to start doing so...

That said, I've applied this to master.

thanks
-- PMM


-- PMM

Re: [Qemu-devel] [PULL 0/5] QMP queue

[Luiz Capitulino]

On Sun, 8 Mar 2015 23:08:04 +0900
Peter Maydell <peter.maydell@linaro.org> wrote:

> On 5 March 2015 at 04:13, Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > Hi,
> >
> > This pull request contains two series. A balloon series and memory hotplug
> > doc series. The balloon series is not totally QMP related, but it has
> > implications to libvirt when using memory hotplug. So, I'm picking it up.
> > The second series is a memory hotplug doc improvement. This is not QMP
> > related at all, but I'm adding it here as it got fully reviewed and is
> > really wanted.
> >
> > The following changes since commit 3539bbb93e944ffde31c61c369ea9eedcc5697a6:
> >
> >   Merge remote-tracking branch 'remotes/awilliam/tags/vfio-update-20150302.0' into staging (2015-03-04 14:37:31 +0000)
> >
> > are available in the git repository at:
> >
> >
> >   git://repo.or.cz/qemu/qmp-unstable.git queue/qmp
> >
> > for you to fetch changes up to a3b042179859c68b3d08f8aa43866d28d6b56987:
> >
> >   docs: add memory-hotplug.txt (2015-03-04 13:00:36 -0500)
> 
> Nudge: this isn't a signed pull request. I'm not currently rejecting
> unsigned pulls, but at some point in the not very distant future
> (maybe after 2.3?) I plan to start doing so...

My bad. I knew there was something missing when I was fixing my
scripts after a long time without sending pull requests. Sorry
about that.

> That said, I've applied this to master.

Thanks.