Re: [PATCH v1 23/26] qemu: Wire up MEMORY_DEVICE_SIZE_CHANGE event

2020-12-02 Thread Michal Privoznik

On 11/30/20 10:44 PM, Daniel Henrique Barboza wrote:



On 11/27/20 12:03 PM, Michal Privoznik wrote:

As advertised in previous commit, this event is delivered to us
when virtio-mem module changes the allocation inside the guest.
It comes with one attribute - size - which holds the new size of
the virtio-mem (well, allocated size), in bytes.
Mind you, this is not necessarily the same number as 'requested
size'. It almost certainly will be when sizing the memory up, but
it might not be when sizing the memory down - the guest kernel
might be unable to free some blocks.

This actual size is reported in the domain XML as an output
element only.

TODO: Fix up total domain memory calculation.


I don't mind the 'TODO' here, but it would be good to clarify what
we can/can't expect while this isn't looked at.

E.g. I took the series for a spin in my x86 dev box (apparently pSeries
does no support virtio-pmem and virtio-mem, so here I am doing x86
work hehe) and I saw that  'virsh setmem --virtio' does not update the
'maxMemory' of the live XML. Is that the intended effect of this pending
'TODO' the commit is referring to?


That is the part that's missing, yes, that's what the TODO is refering 
to. Let me see if I can get my head around it this time.


Michal



Re: [PATCH v1 23/26] qemu: Wire up MEMORY_DEVICE_SIZE_CHANGE event

2020-11-30 Thread Daniel Henrique Barboza




On 11/27/20 12:03 PM, Michal Privoznik wrote:

As advertised in previous commit, this event is delivered to us
when virtio-mem module changes the allocation inside the guest.
It comes with one attribute - size - which holds the new size of
the virtio-mem (well, allocated size), in bytes.
Mind you, this is not necessarily the same number as 'requested
size'. It almost certainly will be when sizing the memory up, but
it might not be when sizing the memory down - the guest kernel
might be unable to free some blocks.

This actual size is reported in the domain XML as an output
element only.

TODO: Fix up total domain memory calculation.


I don't mind the 'TODO' here, but it would be good to clarify what
we can/can't expect while this isn't looked at.

E.g. I took the series for a spin in my x86 dev box (apparently pSeries
does no support virtio-pmem and virtio-mem, so here I am doing x86
work hehe) and I saw that  'virsh setmem --virtio' does not update the
'maxMemory' of the live XML. Is that the intended effect of this pending
'TODO' the commit is referring to?


Code LGTM.


Reviewed-by: Daniel Henrique Barboza 




Signed-off-by: Michal Privoznik 
---
  docs/formatdomain.rst |  7 ++
  docs/schemas/domaincommon.rng |  5 +
  src/conf/domain_conf.c| 24 ++--
  src/conf/domain_conf.h|  7 ++
  src/libvirt_private.syms  |  1 +
  src/qemu/qemu_domain.c|  3 +++
  src/qemu/qemu_domain.h|  1 +
  src/qemu/qemu_driver.c| 33 
  src/qemu/qemu_monitor.c   | 24 
  src/qemu/qemu_monitor.h   | 20 +
  src/qemu/qemu_monitor_json.c  | 24 
  src/qemu/qemu_process.c   | 41 +++
  12 files changed, 188 insertions(+), 2 deletions(-)

diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 3990728939..ac87d03b33 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -7196,6 +7196,7 @@ Example: usage of the memory devices
   0
   2048
   524288
+ 524288
 
   
   
@@ -7322,6 +7323,12 @@ Example: usage of the memory devices
   granularity. This is valid for ``virtio`` model only and mutually
   exclusive with ``pmem``.
  
+   ``actual``

+ The active XML for a ``virtio`` model may contain ``actual`` element that
+ reflects the actual size of the corresponding virtio memory device. The
+ element is formatted into live XML and never parsed, i.e. it is
+ output-only element.
+
  :anchor:``
  
  IOMMU devices

diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index d478b639fa..3b12902e04 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -6063,6 +6063,11 @@
  

  
+
+  
+
+  
+
  

  
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 5db1fee16b..05f5d70cee 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -18804,6 +18804,21 @@ virDomainMemoryFindByDeviceInfo(virDomainDefPtr def,
  }
  
  
+ssize_t

+virDomainMemoryFindByDeviceAlias(virDomainDefPtr def,
+ const char *alias)
+{
+size_t i;
+
+for (i = 0; i < def->nmems; i++) {
+if (STREQ_NULLABLE(def->mems[i]->info.alias, alias))
+return i;
+}
+
+return -1;
+}
+
+
  /**
   * virDomainMemoryInsert:
   *
@@ -28124,7 +28139,8 @@ virDomainMemorySourceDefFormat(virBufferPtr buf,
  
  static void

  virDomainMemoryTargetDefFormat(virBufferPtr buf,
-   virDomainMemoryDefPtr def)
+   virDomainMemoryDefPtr def,
+   unsigned int flags)
  {
  g_auto(virBuffer) childBuf = VIR_BUFFER_INIT_CHILD(buf);
  
@@ -28146,6 +28162,10 @@ virDomainMemoryTargetDefFormat(virBufferPtr buf,
  
  virBufferAsprintf(, "%llu\n",

def->requestedsize);
+if (!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)) {
+virBufferAsprintf(, "%llu\n",
+  def->actualsize);
+}
  }
  
  virXMLFormatElement(buf, "target", NULL, );

@@ -28180,7 +28200,7 @@ virDomainMemoryDefFormat(virBufferPtr buf,
  if (virDomainMemorySourceDefFormat(buf, def) < 0)
  return -1;
  
-virDomainMemoryTargetDefFormat(buf, def);

+virDomainMemoryTargetDefFormat(buf, def, flags);
  
  virDomainDeviceInfoFormat(buf, >info, flags);
  
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h

index 31892c4941..633c07b59c 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2342,6 +2342,9 @@ struct _virDomainMemoryDef {
  unsigned long long labelsize; /* kibibytes; valid only for NVDIMM */
  unsigned long long blocksize; /* kibibytes, valid for virtio-mem only */
  unsigned 

[PATCH v1 23/26] qemu: Wire up MEMORY_DEVICE_SIZE_CHANGE event

2020-11-27 Thread Michal Privoznik
As advertised in previous commit, this event is delivered to us
when virtio-mem module changes the allocation inside the guest.
It comes with one attribute - size - which holds the new size of
the virtio-mem (well, allocated size), in bytes.
Mind you, this is not necessarily the same number as 'requested
size'. It almost certainly will be when sizing the memory up, but
it might not be when sizing the memory down - the guest kernel
might be unable to free some blocks.

This actual size is reported in the domain XML as an output
element only.

TODO: Fix up total domain memory calculation.

Signed-off-by: Michal Privoznik 
---
 docs/formatdomain.rst |  7 ++
 docs/schemas/domaincommon.rng |  5 +
 src/conf/domain_conf.c| 24 ++--
 src/conf/domain_conf.h|  7 ++
 src/libvirt_private.syms  |  1 +
 src/qemu/qemu_domain.c|  3 +++
 src/qemu/qemu_domain.h|  1 +
 src/qemu/qemu_driver.c| 33 
 src/qemu/qemu_monitor.c   | 24 
 src/qemu/qemu_monitor.h   | 20 +
 src/qemu/qemu_monitor_json.c  | 24 
 src/qemu/qemu_process.c   | 41 +++
 12 files changed, 188 insertions(+), 2 deletions(-)

diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 3990728939..ac87d03b33 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -7196,6 +7196,7 @@ Example: usage of the memory devices
  0
  2048
  524288
+ 524288

  
  
@@ -7322,6 +7323,12 @@ Example: usage of the memory devices
  granularity. This is valid for ``virtio`` model only and mutually
  exclusive with ``pmem``.
 
+   ``actual``
+ The active XML for a ``virtio`` model may contain ``actual`` element that
+ reflects the actual size of the corresponding virtio memory device. The
+ element is formatted into live XML and never parsed, i.e. it is
+ output-only element.
+
 :anchor:``
 
 IOMMU devices
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index d478b639fa..3b12902e04 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -6063,6 +6063,11 @@
 
   
 
+
+  
+
+  
+
 
   
 
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 5db1fee16b..05f5d70cee 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -18804,6 +18804,21 @@ virDomainMemoryFindByDeviceInfo(virDomainDefPtr def,
 }
 
 
+ssize_t
+virDomainMemoryFindByDeviceAlias(virDomainDefPtr def,
+ const char *alias)
+{
+size_t i;
+
+for (i = 0; i < def->nmems; i++) {
+if (STREQ_NULLABLE(def->mems[i]->info.alias, alias))
+return i;
+}
+
+return -1;
+}
+
+
 /**
  * virDomainMemoryInsert:
  *
@@ -28124,7 +28139,8 @@ virDomainMemorySourceDefFormat(virBufferPtr buf,
 
 static void
 virDomainMemoryTargetDefFormat(virBufferPtr buf,
-   virDomainMemoryDefPtr def)
+   virDomainMemoryDefPtr def,
+   unsigned int flags)
 {
 g_auto(virBuffer) childBuf = VIR_BUFFER_INIT_CHILD(buf);
 
@@ -28146,6 +28162,10 @@ virDomainMemoryTargetDefFormat(virBufferPtr buf,
 
 virBufferAsprintf(, "%llu\n",
   def->requestedsize);
+if (!(flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE)) {
+virBufferAsprintf(, "%llu\n",
+  def->actualsize);
+}
 }
 
 virXMLFormatElement(buf, "target", NULL, );
@@ -28180,7 +28200,7 @@ virDomainMemoryDefFormat(virBufferPtr buf,
 if (virDomainMemorySourceDefFormat(buf, def) < 0)
 return -1;
 
-virDomainMemoryTargetDefFormat(buf, def);
+virDomainMemoryTargetDefFormat(buf, def, flags);
 
 virDomainDeviceInfoFormat(buf, >info, flags);
 
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 31892c4941..633c07b59c 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2342,6 +2342,9 @@ struct _virDomainMemoryDef {
 unsigned long long labelsize; /* kibibytes; valid only for NVDIMM */
 unsigned long long blocksize; /* kibibytes, valid for virtio-mem only */
 unsigned long long requestedsize; /* kibibytes, valid for virtio-mem only 
*/
+unsigned long long actualsize; /* kibibytes, valid for virtio-mem and
+  active domain only, only to report never
+  parse */
 bool readonly; /* valid only for NVDIMM */
 
 /* required for QEMU NVDIMM ppc64 support */
@@ -3584,6 +3587,10 @@ ssize_t virDomainMemoryFindByDeviceInfo(virDomainDefPtr 
dev,
 virDomainDeviceInfoPtr info)
 ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) G_GNUC_WARN_UNUSED_RESULT;
 
+ssize_t