4:05 p.m.
*** BLURB HERE ***
Michal Prívozník (4):
conf: Introduce memory allocation threads
qemu_capabilities: Detect memory-backend-*.prealloc-threads property
qemu_validate: Validate prealloc threads against qemuCpas
qemu_command: Generate prealloc-threads property
docs/formatdomain.rst | 6 ++++--
docs/schemas/domaincommon.rng | 19 +++++++++++++------
src/conf/domain_conf.c | 15 ++++++++++++++-
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 5 ++++-
src/qemu/qemu_validate.c | 7 +++++++
.../caps_5.0.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
.../caps_5.0.0.riscv64.xml | 1 +
.../caps_5.0.0.x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 +
.../caps_5.1.0.x86_64.xml | 1 +
.../caps_5.2.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 +
.../caps_5.2.0.riscv64.xml | 1 +
.../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 +
.../caps_5.2.0.x86_64.xml | 1 +
.../caps_6.0.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 +
.../caps_6.0.0.x86_64.xml | 1 +
.../caps_6.1.0.x86_64.xml | 1 +
.../caps_6.2.0.aarch64.xml | 1 +
.../qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 +
.../caps_6.2.0.x86_64.xml | 1 +
.../qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 +
.../caps_7.0.0.x86_64.xml | 1 +
.../memfd-memory-numa.x86_64-latest.args | 4 ++--
tests/qemuxml2argvdata/memfd-memory-numa.xml | 2 +-
30 files changed, 69 insertions(+), 13 deletions(-)
--
2.34.1
4:05 p.m.
New subject: [PATCH 1/4] conf: Introduce memory allocation threads
Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable of
specifying number of threads used to allocate memory. While it
defaults to the number of vCPUs, users might want to use a
different value (especially for humongous guests with gigantic
pages).
In general, on QEMU cmd line level it is possible to use
different number of threads per each memory-backend-* object, in
practical terms it's not useful. Therefore, use <memoryBacking/>
to set guest wide value and let all memory devices 'inherit' it,
silently. IOW, don't introduce per device knob because that would
only complicate things for a little or no benefit.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/formatdomain.rst | 6 ++++--
docs/schemas/domaincommon.rng | 19 +++++++++++++------
src/conf/domain_conf.c | 15 ++++++++++++++-
src/conf/domain_conf.h | 1 +
tests/qemuxml2argvdata/memfd-memory-numa.xml | 2 +-
5 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 9b1b69bb4d..8e25474db0 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -1004,7 +1004,7 @@ Memory Backing
<locked/>
<source type="file|anonymous|memfd"/>
<access mode="shared|private"/>
- <allocation mode="immediate|ondemand"/>
+ <allocation mode="immediate|ondemand" threads='8'/>
<discard/>
</memoryBacking>
...
@@ -1054,7 +1054,9 @@ influence how virtual memory pages are backed by host pages.
"private". This can be overridden per numa node by ``memAccess``.
``allocation``
Using the ``mode`` attribute, specify when to allocate the memory by
- supplying either "immediate" or "ondemand".
+ supplying either "immediate" or "ondemand". :since:`Since 8.2.0`
this
+ attribute is optional among with ``threads`` attribute, that sets the number
+ of threads that hypervisor uses to allocate memory.
``discard``
When set and supported by hypervisor the memory content is discarded just
before guest shuts down (or when DIMM module is unplugged). Please note that
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 9c1b64a644..34bccee2f5 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -740,12 +740,19 @@
</optional>
<optional>
<element name="allocation">
- <attribute name="mode">
- <choice>
- <value>immediate</value>
- <value>ondemand</value>
- </choice>
- </attribute>
+ <optional>
+ <attribute name="mode">
+ <choice>
+ <value>immediate</value>
+ <value>ondemand</value>
+ </choice>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="threads">
+ <ref name="unsignedInt"/>
+ </attribute>
+ </optional>
</element>
</optional>
<optional>
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e0dfc9e45f..2414a806d0 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -18914,6 +18914,13 @@ virDomainDefParseMemory(virDomainDef *def,
VIR_FREE(tmp);
}
+ if (virXPathUInt("string(./memoryBacking/allocation/@threads)",
+ ctxt, &def->mem.allocation_threads) == -2) {
+ virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("Failed to parse memory allocation threads"));
+ return -1;
+ }
+
if (virXPathNode("./memoryBacking/hugepages", ctxt)) {
/* hugepages will be used */
if ((n = virXPathNodeSet("./memoryBacking/hugepages/page", ctxt,
&nodes)) < 0) {
@@ -27464,6 +27471,7 @@ virDomainMemorybackingFormat(virBuffer *buf,
const virDomainMemtune *mem)
{
g_auto(virBuffer) childBuf = VIR_BUFFER_INIT_CHILD(buf);
+ g_auto(virBuffer) allocAttrBuf = VIR_BUFFER_INITIALIZER;
if (mem->nhugepages)
virDomainHugepagesFormat(&childBuf, mem->hugepages, mem->nhugepages);
@@ -27478,8 +27486,13 @@ virDomainMemorybackingFormat(virBuffer *buf,
virBufferAsprintf(&childBuf, "<access
mode='%s'/>\n",
virDomainMemoryAccessTypeToString(mem->access));
if (mem->allocation)
- virBufferAsprintf(&childBuf, "<allocation
mode='%s'/>\n",
+ virBufferAsprintf(&allocAttrBuf, " mode='%s'",
virDomainMemoryAllocationTypeToString(mem->allocation));
+ if (mem->allocation_threads)
+ virBufferAsprintf(&allocAttrBuf, " threads='%u'",
mem->allocation_threads);
+
+ virXMLFormatElement(&childBuf, "allocation", &allocAttrBuf, NULL);
+
if (mem->discard)
virBufferAddLit(&childBuf, "<discard/>\n");
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index a4de46773c..48df6cc389 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2701,6 +2701,7 @@ struct _virDomainMemtune {
int source; /* enum virDomainMemorySource */
int access; /* enum virDomainMemoryAccess */
int allocation; /* enum virDomainMemoryAllocation */
+ unsigned int allocation_threads;
virTristateBool discard;
};
diff --git a/tests/qemuxml2argvdata/memfd-memory-numa.xml
b/tests/qemuxml2argvdata/memfd-memory-numa.xml
index 1ebcee8939..1ac87e3aef 100644
--- a/tests/qemuxml2argvdata/memfd-memory-numa.xml
+++ b/tests/qemuxml2argvdata/memfd-memory-numa.xml
@@ -10,7 +10,7 @@
</hugepages>
<source type='memfd'/>
<access mode='shared'/>
- <allocation mode='immediate'/>
+ <allocation mode='immediate' threads='8'/>
</memoryBacking>
<vcpu placement='static'>8</vcpu>
<numatune>
--
2.34.1
8:48 a.m.
New subject: [PATCH 1/4] conf: Introduce memory allocation threads
On 3/22/22 16:05, Michal Privoznik wrote:
Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable of
specifying number of threads used to allocate memory. While it
defaults to the number of vCPUs, users might want to use a
different value (especially for humongous guests with gigantic
pages).
Err, this statement is not correct. The default value is 1 and not
number of vCPUs. If it was numbed of vCPUs then these patches would be
that necessary. I've reworded this paragraph locally to:
Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable of
specifying number of threads used to allocate memory. It defaults
to 1, which may be too low for humongous guests with gigantic
pages.
Thank to David Hildebrand for pointing this out to me.
Michal
10:26 a.m.
New subject: [PATCH 1/4] conf: Introduce memory allocation threads
On Tue, Mar 22, 2022 at 04:05:14PM +0100, Michal Privoznik wrote:
Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable of
Anything wrong with the old "commit ffac16fab33b" ?
specifying number of threads used to allocate memory. While it
defaults to the number of vCPUs, users might want to use a
different value (especially for humongous guests with gigantic
pages).
In general, on QEMU cmd line level it is possible to use
different number of threads per each memory-backend-* object, in
practical terms it's not useful. Therefore, use <memoryBacking/>
to set guest wide value and let all memory devices 'inherit' it,
silently. IOW, don't introduce per device knob because that would
only complicate things for a little or no benefit.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/formatdomain.rst | 6 ++++--
docs/schemas/domaincommon.rng | 19 +++++++++++++------
src/conf/domain_conf.c | 15 ++++++++++++++-
src/conf/domain_conf.h | 1 +
tests/qemuxml2argvdata/memfd-memory-numa.xml | 2 +-
5 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 9b1b69bb4d..8e25474db0 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -1004,7 +1004,7 @@ Memory Backing
<locked/>
<source type="file|anonymous|memfd"/>
<access mode="shared|private"/>
- <allocation mode="immediate|ondemand"/>
+ <allocation mode="immediate|ondemand" threads='8'/>
<discard/>
</memoryBacking>
...
@@ -1054,7 +1054,9 @@ influence how virtual memory pages are backed by host pages.
"private". This can be overridden per numa node by ``memAccess``.
``allocation``
Using the ``mode`` attribute, specify when to allocate the memory by
- supplying either "immediate" or "ondemand".
+ supplying either "immediate" or "ondemand". :since:`Since 8.2.0`
this
+ attribute is optional among with ``threads`` attribute, that sets the number
+ of threads that hypervisor uses to allocate memory.
This is weird to read. Just say "Using the optional mode attribute" and
refer to threads as optional too. If anyone wants to use just the
allocation threads and leave out the mode they have to be on 8.2.0
anyway, so no need to complicate things.
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index e0dfc9e45f..2414a806d0 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -18914,6 +18914,13 @@ virDomainDefParseMemory(virDomainDef *def,
VIR_FREE(tmp);
}
+ if (virXPathUInt("string(./memoryBacking/allocation/@threads)",
+ ctxt, &def->mem.allocation_threads) == -2) {
+ virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("Failed to parse memory allocation threads"));
+ return -1;
+ }
+
if (virXPathNode("./memoryBacking/hugepages", ctxt)) {
/* hugepages will be used */
if ((n = virXPathNodeSet("./memoryBacking/hugepages/page", ctxt,
&nodes)) < 0) {
@@ -27464,6 +27471,7 @@ virDomainMemorybackingFormat(virBuffer *buf,
const virDomainMemtune *mem)
{
g_auto(virBuffer) childBuf = VIR_BUFFER_INIT_CHILD(buf);
+ g_auto(virBuffer) allocAttrBuf = VIR_BUFFER_INITIALIZER;
if (mem->nhugepages)
virDomainHugepagesFormat(&childBuf, mem->hugepages, mem->nhugepages);
@@ -27478,8 +27486,13 @@ virDomainMemorybackingFormat(virBuffer *buf,
virBufferAsprintf(&childBuf, "<access
mode='%s'/>\n",
virDomainMemoryAccessTypeToString(mem->access));
if (mem->allocation)
- virBufferAsprintf(&childBuf, "<allocation
mode='%s'/>\n",
+ virBufferAsprintf(&allocAttrBuf, " mode='%s'",
virDomainMemoryAllocationTypeToString(mem->allocation));
+ if (mem->allocation_threads)
Here you check if (mem->allocation_threads), but in 3/4 you check if
(allocation_threads > 0), which is a bit inconsistent. I prefer the
former although I know we had some disputes with this, so pick whatever
one and make it consistent.
12:15 p.m.
New subject: [PATCH 1/4] conf: Introduce memory allocation threads
On 3/24/22 10:26, Martin Kletzander wrote:
On Tue, Mar 22, 2022 at 04:05:14PM +0100, Michal Privoznik wrote:
> Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable of
Anything wrong with the old "commit ffac16fab33b" ?
Not specifically no. But I do it this ways so that it's visible at the
first sight what QEMU version was this feature introduced in. And it
works with 'git show' too (for those who are interested in the
particular commit). IOW:
"Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable .."
contains more information than:
"Since its commit ffac16fab33b QEMU is capable .."
But I don't care that much. I agree that in this particular case it's a
bit messy, because QEMU doesn't have linear history. It's way nicer with
libvirt commits.
> specifying number of threads used to allocate memory. While it
> defaults to the number of vCPUs, users might want to use a
> different value (especially for humongous guests with gigantic
> pages).
>
> In general, on QEMU cmd line level it is possible to use
> different number of threads per each memory-backend-* object, in
> practical terms it's not useful. Therefore, use <memoryBacking/>
> to set guest wide value and let all memory devices 'inherit' it,
> silently. IOW, don't introduce per device knob because that would
> only complicate things for a little or no benefit.
>
> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
> ---
> docs/formatdomain.rst | 6 ++++--
> docs/schemas/domaincommon.rng | 19 +++++++++++++------
> src/conf/domain_conf.c | 15 ++++++++++++++-
> src/conf/domain_conf.h | 1 +
> tests/qemuxml2argvdata/memfd-memory-numa.xml | 2 +-
> 5 files changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
> index 9b1b69bb4d..8e25474db0 100644
> --- a/docs/formatdomain.rst
> +++ b/docs/formatdomain.rst
> @@ -1004,7 +1004,7 @@ Memory Backing
> <locked/>
> <source type="file|anonymous|memfd"/>
> <access mode="shared|private"/>
> - <allocation mode="immediate|ondemand"/>
> + <allocation mode="immediate|ondemand" threads='8'/>
> <discard/>
> </memoryBacking>
> ...
> @@ -1054,7 +1054,9 @@ influence how virtual memory pages are backed by
> host pages.
> "private". This can be overridden per numa node by ``memAccess``.
> ``allocation``
> Using the ``mode`` attribute, specify when to allocate the memory by
> - supplying either "immediate" or "ondemand".
> + supplying either "immediate" or "ondemand". :since:`Since
8.2.0` this
> + attribute is optional among with ``threads`` attribute, that sets
> the number
> + of threads that hypervisor uses to allocate memory.
This is weird to read. Just say "Using the optional mode attribute" and
refer to threads as optional too. If anyone wants to use just the
allocation threads and leave out the mode they have to be on 8.2.0
anyway, so no need to complicate things.
Alright, fair enough.
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index e0dfc9e45f..2414a806d0 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -18914,6 +18914,13 @@ virDomainDefParseMemory(virDomainDef *def,
> VIR_FREE(tmp);
> }
>
> + if (virXPathUInt("string(./memoryBacking/allocation/@threads)",
> + ctxt, &def->mem.allocation_threads) == -2) {
> + virReportError(VIR_ERR_XML_ERROR, "%s",
> + _("Failed to parse memory allocation threads"));
> + return -1;
> + }
> +
> if (virXPathNode("./memoryBacking/hugepages", ctxt)) {
> /* hugepages will be used */
> if ((n = virXPathNodeSet("./memoryBacking/hugepages/page",
> ctxt, &nodes)) < 0) {
> @@ -27464,6 +27471,7 @@ virDomainMemorybackingFormat(virBuffer *buf,
> const virDomainMemtune *mem)
> {
> g_auto(virBuffer) childBuf = VIR_BUFFER_INIT_CHILD(buf);
> + g_auto(virBuffer) allocAttrBuf = VIR_BUFFER_INITIALIZER;
>
> if (mem->nhugepages)
> virDomainHugepagesFormat(&childBuf, mem->hugepages,
> mem->nhugepages);
> @@ -27478,8 +27486,13 @@ virDomainMemorybackingFormat(virBuffer *buf,
> virBufferAsprintf(&childBuf, "<access
mode='%s'/>\n",
>
> virDomainMemoryAccessTypeToString(mem->access));
> if (mem->allocation)
> - virBufferAsprintf(&childBuf, "<allocation
mode='%s'/>\n",
> + virBufferAsprintf(&allocAttrBuf, " mode='%s'",
>
> virDomainMemoryAllocationTypeToString(mem->allocation));
> + if (mem->allocation_threads)
Here you check if (mem->allocation_threads), but in 3/4 you check if
(allocation_threads > 0), which is a bit inconsistent. I prefer the
former although I know we had some disputes with this, so pick whatever
one and make it consistent.
D'oh! I remember I wanted to fix this. > 0 it is.
Michal
12:22 p.m.
New subject: [PATCH 1/4] conf: Introduce memory allocation threads
On Thu, Mar 24, 2022 at 12:15:43PM +0100, Michal Prívozník wrote:
On 3/24/22 10:26, Martin Kletzander wrote:
> On Tue, Mar 22, 2022 at 04:05:14PM +0100, Michal Privoznik wrote:
>> Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable of
>
> Anything wrong with the old "commit ffac16fab33b" ?
Not specifically no. But I do it this ways so that it's visible at the
first sight what QEMU version was this feature introduced in. And it
works with 'git show' too (for those who are interested in the
particular commit). IOW:
"Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable .."
How do you generate such a reference ? It is different from
what a simple git describe shows
$ git describe --match 'v*' ffac16fab33b
v4.2.0-1618-gffac16fab3
and I feel the git describe output is much nicer, as it actually
includes the commit short hash still.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
12:49 p.m.
New subject: [PATCH 1/4] conf: Introduce memory allocation threads
On Thu, Mar 24, 2022 at 11:22:54AM +0000, Daniel P. Berrangé wrote:
On Thu, Mar 24, 2022 at 12:15:43PM +0100, Michal Prívozník wrote:
> On 3/24/22 10:26, Martin Kletzander wrote:
> > On Tue, Mar 22, 2022 at 04:05:14PM +0100, Michal Privoznik wrote:
> >> Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable of
> >
> > Anything wrong with the old "commit ffac16fab33b" ?
>
> Not specifically no. But I do it this ways so that it's visible at the
> first sight what QEMU version was this feature introduced in. And it
> works with 'git show' too (for those who are interested in the
> particular commit). IOW:
>
> "Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable .."
How do you generate such a reference ? It is different from
what a simple git describe shows
$ git describe --match 'v*' ffac16fab33b
v4.2.0-1618-gffac16fab3
and I feel the git describe output is much nicer, as it actually
includes the commit short hash still.
I think Michal used --contains which clearly shows from which tag is the
commit included, but tracking down through merge commits is what makes
it look like the above.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
2:43 p.m.
New subject: [PATCH 1/4] conf: Introduce memory allocation threads
On 3/24/22 12:49, Martin Kletzander wrote:
On Thu, Mar 24, 2022 at 11:22:54AM +0000, Daniel P. Berrangé wrote:
> On Thu, Mar 24, 2022 at 12:15:43PM +0100, Michal Prívozník wrote:
>> On 3/24/22 10:26, Martin Kletzander wrote:
>> > On Tue, Mar 22, 2022 at 04:05:14PM +0100, Michal Privoznik wrote:
>> >> Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable of
>> >
>> > Anything wrong with the old "commit ffac16fab33b" ?
>>
>> Not specifically no. But I do it this ways so that it's visible at the
>> first sight what QEMU version was this feature introduced in. And it
>> works with 'git show' too (for those who are interested in the
>> particular commit). IOW:
>>
>> "Since its commit v5.0.0-rc0~75^2~1^2~3 QEMU is capable .."
>
> How do you generate such a reference ? It is different from
> what a simple git describe shows
>
> $ git describe --match 'v*' ffac16fab33b
> v4.2.0-1618-gffac16fab3
>
> and I feel the git describe output is much nicer, as it actually
> includes the commit short hash still.
>
I think Michal used --contains which clearly shows from which tag is the
commit included, but tracking down through merge commits is what makes
it look like the above.
Indeed.
qemu.git $ git describe --contains ffac16fab33bb42f17e47624985220c1fd864e9d
v5.0.0-rc0~75^2~1^2~3
Michal
4:05 p.m.
New subject: [PATCH 2/4] qemu_capabilities: Detect memory-backend-*.prealloc-threads property
The prealloc-threads is property of memory-backend class which is
parent to the other three classes memory-backend-{ram,file,memfd}.
Therefore the property is present for all, or none if QEMU is
older than v5.0.0-rc0~75^2~1^2~3 which introduced the property.
Anyway, the .reserve property is the same story, and we chose
memory-backend-file to detect it, so stick with our earlier
decision and use the same backend to detect this new property.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 +
tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml | 1 +
tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 +
tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml | 1 +
tests/qemucapabilitiesdata/caps_6.2.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml | 1 +
tests/qemucapabilitiesdata/caps_7.0.0.ppc64.xml | 1 +
tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml | 1 +
22 files changed, 23 insertions(+)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 32980e7330..6b4ed08499 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -668,6 +668,7 @@ VIR_ENUM_IMPL(virQEMUCaps,
/* 425 */
"blockdev.nbd.tls-hostname", /*
QEMU_CAPS_BLOCKDEV_NBD_TLS_HOSTNAME */
+ "memory-backend-file.prealloc-threads", /*
QEMU_CAPS_MEMORY_BACKEND_PREALLOC_THREADS */
);
@@ -1766,6 +1767,7 @@ static struct virQEMUCapsStringFlags
virQEMUCapsObjectPropsMemoryBackendFile[] =
* released qemu versions. */
{ "x-use-canonical-path-for-ramblock-id",
QEMU_CAPS_X_USE_CANONICAL_PATH_FOR_RAMBLOCK_ID },
{ "reserve", QEMU_CAPS_MEMORY_BACKEND_RESERVE },
+ { "prealloc-threads", QEMU_CAPS_MEMORY_BACKEND_PREALLOC_THREADS },
};
static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsMemoryBackendMemfd[] = {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 0a215a11d5..948029d60d 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -643,6 +643,7 @@ typedef enum { /* virQEMUCapsFlags grouping marker for syntax-check
*/
/* 425 */
QEMU_CAPS_BLOCKDEV_NBD_TLS_HOSTNAME, /* tls hostname can be overriden for NBD clients
*/
+ QEMU_CAPS_MEMORY_BACKEND_PREALLOC_THREADS, /* -object
memory-backend-*.prealloc-threads */
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml
b/tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml
index 4c1a37104c..d188eab3fe 100644
--- a/tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.0.0.aarch64.xml
@@ -178,6 +178,7 @@
<flag name='input-linux'/>
<flag name='query-display-options'/>
<flag name='virtio-blk.queue-size'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>61700241</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
index 070d0f2982..12592f457a 100644
--- a/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
@@ -186,6 +186,7 @@
<flag name='input-linux'/>
<flag name='query-display-options'/>
<flag name='virtio-blk.queue-size'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900241</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml
b/tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml
index 286049a8a6..75c3a9b4fc 100644
--- a/tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.0.0.riscv64.xml
@@ -170,6 +170,7 @@
<flag name='input-linux'/>
<flag name='query-display-options'/>
<flag name='virtio-blk.queue-size'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>0</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml
index f563d672b4..5927c48ee4 100644
--- a/tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.0.0.x86_64.xml
@@ -219,6 +219,7 @@
<flag name='input-linux'/>
<flag name='query-display-options'/>
<flag name='virtio-blk.queue-size'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100241</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml
b/tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml
index 58af90b29f..7de7c291f5 100644
--- a/tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml
+++ b/tests/qemucapabilitiesdata/caps_5.1.0.sparc.xml
@@ -90,6 +90,7 @@
<flag name='rotation-rate'/>
<flag name='input-linux'/>
<flag name='query-display-options'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5001000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>0</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml
index 2d0ef18147..e0291268b3 100644
--- a/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.1.0.x86_64.xml
@@ -222,6 +222,7 @@
<flag name='query-display-options'/>
<flag name='virtio-blk.queue-size'/>
<flag name='virtio-mem-pci'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5001000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100242</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml
b/tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml
index 9f14d59efb..20a1a8154b 100644
--- a/tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.2.0.aarch64.xml
@@ -184,6 +184,7 @@
<flag name='virtio-blk.queue-size'/>
<flag name='query-dirty-rate'/>
<flag name='calc-dirty-rate'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5002000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>61700243</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml
index e050514fc1..add2ded00a 100644
--- a/tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.2.0.ppc64.xml
@@ -190,6 +190,7 @@
<flag name='virtio-blk.queue-size'/>
<flag name='query-dirty-rate'/>
<flag name='calc-dirty-rate'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5002000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900243</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml
b/tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml
index 4b123d4ce9..237d043e5d 100644
--- a/tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.2.0.riscv64.xml
@@ -174,6 +174,7 @@
<flag name='virtio-blk.queue-size'/>
<flag name='query-dirty-rate'/>
<flag name='calc-dirty-rate'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5002000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>0</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml
b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml
index bc3c3c351a..57e40f8f86 100644
--- a/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml
+++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml
@@ -141,6 +141,7 @@
<flag name='virtio-blk.queue-size'/>
<flag name='query-dirty-rate'/>
<flag name='calc-dirty-rate'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5002000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>39100243</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml
index 70ad14f548..7c65648c06 100644
--- a/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_5.2.0.x86_64.xml
@@ -226,6 +226,7 @@
<flag name='piix4.acpi-root-pci-hotplug'/>
<flag name='query-dirty-rate'/>
<flag name='calc-dirty-rate'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>5002000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100243</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml
b/tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml
index 9d501f29af..7557e6ad71 100644
--- a/tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_6.0.0.aarch64.xml
@@ -192,6 +192,7 @@
<flag name='virtio-blk.queue-size'/>
<flag name='query-dirty-rate'/>
<flag name='calc-dirty-rate'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>6000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>61700242</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml
b/tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml
index 02b24f5d7e..00009be3dc 100644
--- a/tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml
+++ b/tests/qemucapabilitiesdata/caps_6.0.0.s390x.xml
@@ -149,6 +149,7 @@
<flag name='virtio-blk.queue-size'/>
<flag name='query-dirty-rate'/>
<flag name='calc-dirty-rate'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>6000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>39100242</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml
index 8ea688f7a6..61d561dc69 100644
--- a/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_6.0.0.x86_64.xml
@@ -235,6 +235,7 @@
<flag name='query-dirty-rate'/>
<flag name='sev-inject-launch-secret'/>
<flag name='calc-dirty-rate'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>6000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100242</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml
index ba1aecc37e..0b58210335 100644
--- a/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_6.1.0.x86_64.xml
@@ -239,6 +239,7 @@
<flag name='rbd-encryption'/>
<flag name='sev-inject-launch-secret'/>
<flag name='calc-dirty-rate'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>6001000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100243</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml
b/tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml
index 17d563eb5b..d08b2c0213 100644
--- a/tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml
+++ b/tests/qemucapabilitiesdata/caps_6.2.0.aarch64.xml
@@ -203,6 +203,7 @@
<flag name='query-dirty-rate'/>
<flag name='rbd-encryption'/>
<flag name='calc-dirty-rate'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>6001050</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>61700244</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_6.2.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_6.2.0.ppc64.xml
index 9fe9c27d14..8c52964ec0 100644
--- a/tests/qemucapabilitiesdata/caps_6.2.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_6.2.0.ppc64.xml
@@ -201,6 +201,7 @@
<flag name='sev-guest-kernel-hashes'/>
<flag name='calc-dirty-rate'/>
<flag name='dirtyrate-param.mode'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>6002000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900244</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml
index d77907af55..cdf72b9ebf 100644
--- a/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_6.2.0.x86_64.xml
@@ -241,6 +241,7 @@
<flag name='sev-inject-launch-secret'/>
<flag name='calc-dirty-rate'/>
<flag name='dirtyrate-param.mode'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>6002000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100244</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_7.0.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_7.0.0.ppc64.xml
index 5d7f283a73..8aba3329ad 100644
--- a/tests/qemucapabilitiesdata/caps_7.0.0.ppc64.xml
+++ b/tests/qemucapabilitiesdata/caps_7.0.0.ppc64.xml
@@ -202,6 +202,7 @@
<flag name='device.json+hotplug'/>
<flag name='calc-dirty-rate'/>
<flag name='dirtyrate-param.mode'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>6002050</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>42900243</microcodeVersion>
diff --git a/tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml
index 0f34a341af..5227e3ee0b 100644
--- a/tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_7.0.0.x86_64.xml
@@ -244,6 +244,7 @@
<flag name='calc-dirty-rate'/>
<flag name='dirtyrate-param.mode'/>
<flag name='blockdev.nbd.tls-hostname'/>
+ <flag name='memory-backend-file.prealloc-threads'/>
<version>6002050</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100243</microcodeVersion>
--
2.34.1
10:26 a.m.
New subject: [PATCH 2/4] qemu_capabilities: Detect memory-backend-*.prealloc-threads property
On Tue, Mar 22, 2022 at 04:05:15PM +0100, Michal Privoznik wrote:
The prealloc-threads is property of memory-backend class which is
parent to the other three classes memory-backend-{ram,file,memfd}.
Therefore the property is present for all, or none if QEMU is
older than v5.0.0-rc0~75^2~1^2~3 which introduced the property.
Anyway, the .reserve property is the same story, and we chose
memory-backend-file to detect it, so stick with our earlier
decision and use the same backend to detect this new property.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Martin Kletzander <mkletzan(a)redhat.com>
4:05 p.m.
New subject: [PATCH 3/4] qemu_validate: Validate prealloc threads against qemuCpas
Only fairly new QEMUs are capable of user provided number of
preallocation threads. Validate this assumption.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_validate.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/qemu/qemu_validate.c b/src/qemu/qemu_validate.c
index f27e480696..e0708b8a76 100644
--- a/src/qemu/qemu_validate.c
+++ b/src/qemu/qemu_validate.c
@@ -739,6 +739,13 @@ qemuValidateDomainDefMemory(const virDomainDef *def,
return -1;
}
+ if (mem->allocation_threads > 0 &&
+ !virQEMUCapsGet(qemuCaps, QEMU_CAPS_MEMORY_BACKEND_PREALLOC_THREADS)) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
+ _("preallocation threads are unsupported with this
QEMU"));
+ return -1;
+ }
+
if (mem->source == VIR_DOMAIN_MEMORY_SOURCE_ANONYMOUS) {
virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
_("hugepages are not allowed with anonymous "
--
2.34.1
10:27 a.m.
New subject: [PATCH 3/4] qemu_validate: Validate prealloc threads against qemuCpas
On Tue, Mar 22, 2022 at 04:05:16PM +0100, Michal Privoznik wrote:
Only fairly new QEMUs are capable of user provided number of
preallocation threads. Validate this assumption.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Martin Kletzander <mkletzan(a)redhat.com>
4:05 p.m.
New subject: [PATCH 4/4] qemu_command: Generate prealloc-threads property
Let's generate prealloc-threads property onto the cmd line if
domain configuration requests so.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_command.c | 5 ++++-
tests/qemuxml2argvdata/memfd-memory-numa.x86_64-latest.args | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index c836799888..8246ab515a 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3806,7 +3806,10 @@ qemuBuildMemoryBackendProps(virJSONValue **backendProps,
return -1;
} else {
if (!priv->memPrealloc &&
- virJSONValueObjectAdd(&props, "B:prealloc", prealloc, NULL)
< 0)
+ virJSONValueObjectAdd(&props,
+ "B:prealloc", prealloc,
+ "p:prealloc-threads",
def->mem.allocation_threads,
+ NULL) < 0)
return -1;
}
diff --git a/tests/qemuxml2argvdata/memfd-memory-numa.x86_64-latest.args
b/tests/qemuxml2argvdata/memfd-memory-numa.x86_64-latest.args
index 6f5a983d3a..68bbd73551 100644
--- a/tests/qemuxml2argvdata/memfd-memory-numa.x86_64-latest.args
+++ b/tests/qemuxml2argvdata/memfd-memory-numa.x86_64-latest.args
@@ -16,7 +16,7 @@ XDG_CONFIG_HOME=/tmp/lib/domain--1-instance-00000092/.config \
-m size=14680064k,slots=16,maxmem=1099511627776k \
-overcommit mem-lock=off \
-smp 8,sockets=1,dies=1,cores=8,threads=1 \
--object
'{"qom-type":"memory-backend-memfd","id":"ram-node0","hugetlb":true,"hugetlbsize":2097152,"share":true,"prealloc":true,"size":15032385536,"host-nodes":[3],"policy":"preferred"}'
\
+-object
'{"qom-type":"memory-backend-memfd","id":"ram-node0","hugetlb":true,"hugetlbsize":2097152,"share":true,"prealloc":true,"prealloc-threads":8,"size":15032385536,"host-nodes":[3],"policy":"preferred"}'
\
-numa node,nodeid=0,cpus=0-7,memdev=ram-node0 \
-uuid 126f2720-6f8e-45ab-a886-ec9277079a67 \
-display none \
@@ -29,7 +29,7 @@ XDG_CONFIG_HOME=/tmp/lib/domain--1-instance-00000092/.config \
-no-acpi \
-boot strict=on \
-device
'{"driver":"piix3-usb-uhci","id":"usb","bus":"pci.0","addr":"0x1.0x2"}'
\
--object
'{"qom-type":"memory-backend-file","id":"memnvdimm0","mem-path":"/tmp/nvdimm","share":true,"prealloc":true,"size":536870912,"host-nodes":[3],"policy":"preferred"}'
\
+-object
'{"qom-type":"memory-backend-file","id":"memnvdimm0","mem-path":"/tmp/nvdimm","share":true,"prealloc":true,"prealloc-threads":8,"size":536870912,"host-nodes":[3],"policy":"preferred"}'
\
-device
'{"driver":"nvdimm","node":0,"memdev":"memnvdimm0","id":"nvdimm0","slot":0}'
\
-audiodev
'{"id":"audio1","driver":"none"}' \
-device
'{"driver":"virtio-balloon-pci","id":"balloon0","bus":"pci.0","addr":"0x3"}'
\
--
2.34.1
10:27 a.m.
New subject: [PATCH 4/4] qemu_command: Generate prealloc-threads property
On Tue, Mar 22, 2022 at 04:05:17PM +0100, Michal Privoznik wrote:
Let's generate prealloc-threads property onto the cmd line if
domain configuration requests so.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Martin Kletzander <mkletzan(a)redhat.com>
12:16 p.m.
New subject: [PATCH v2] conf: Introduce memory allocation threads
Since its v5.0.0 release QEMU is capable of specifying number of
threads used to allocate memory. It defaults to 1, which may be
too low for humongous guests with gigantic pages.
In general, on QEMU cmd line level it is possible to use
different number of threads per each memory-backend-* object, in
practical terms it's not useful. Therefore, use <memoryBacking/>
to set guest wide value and let all memory devices 'inherit' it,
silently. IOW, don't introduce per device knob because that would
only complicate things for a little or no benefit.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/formatdomain.rst | 8 +++++---
src/conf/domain_conf.c | 15 ++++++++++++++-
src/conf/domain_conf.h | 1 +
src/conf/schemas/domaincommon.rng | 19 +++++++++++++------
tests/qemuxml2argvdata/memfd-memory-numa.xml | 2 +-
5 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index d188de4858..e492532004 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -1004,7 +1004,7 @@ Memory Backing
<locked/>
<source type="file|anonymous|memfd"/>
<access mode="shared|private"/>
- <allocation mode="immediate|ondemand"/>
+ <allocation mode="immediate|ondemand" threads='8'/>
<discard/>
</memoryBacking>
...
@@ -1053,8 +1053,10 @@ influence how virtual memory pages are backed by host pages.
Using the ``mode`` attribute, specify if the memory is to be "shared" or
"private". This can be overridden per numa node by ``memAccess``.
``allocation``
- Using the ``mode`` attribute, specify when to allocate the memory by
- supplying either "immediate" or "ondemand".
+ Using the optional ``mode`` attribute, specify when to allocate the memory by
+ supplying either "immediate" or "ondemand". :since:`Since 8.2.0`
it is
+ possible to set the number of threads that hypervisor uses to allocate
+ memory via ``threads`` attribute.
``discard``
When set and supported by hypervisor the memory content is discarded just
before guest shuts down (or when DIMM module is unplugged). Please note that
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 153954a0b0..731139f80f 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -18915,6 +18915,13 @@ virDomainDefParseMemory(virDomainDef *def,
VIR_FREE(tmp);
}
+ if (virXPathUInt("string(./memoryBacking/allocation/@threads)",
+ ctxt, &def->mem.allocation_threads) == -2) {
+ virReportError(VIR_ERR_XML_ERROR, "%s",
+ _("Failed to parse memory allocation threads"));
+ return -1;
+ }
+
if (virXPathNode("./memoryBacking/hugepages", ctxt)) {
/* hugepages will be used */
if ((n = virXPathNodeSet("./memoryBacking/hugepages/page", ctxt,
&nodes)) < 0) {
@@ -27465,6 +27472,7 @@ virDomainMemorybackingFormat(virBuffer *buf,
const virDomainMemtune *mem)
{
g_auto(virBuffer) childBuf = VIR_BUFFER_INIT_CHILD(buf);
+ g_auto(virBuffer) allocAttrBuf = VIR_BUFFER_INITIALIZER;
if (mem->nhugepages)
virDomainHugepagesFormat(&childBuf, mem->hugepages, mem->nhugepages);
@@ -27479,8 +27487,13 @@ virDomainMemorybackingFormat(virBuffer *buf,
virBufferAsprintf(&childBuf, "<access
mode='%s'/>\n",
virDomainMemoryAccessTypeToString(mem->access));
if (mem->allocation)
- virBufferAsprintf(&childBuf, "<allocation
mode='%s'/>\n",
+ virBufferAsprintf(&allocAttrBuf, " mode='%s'",
virDomainMemoryAllocationTypeToString(mem->allocation));
+ if (mem->allocation_threads > 0)
+ virBufferAsprintf(&allocAttrBuf, " threads='%u'",
mem->allocation_threads);
+
+ virXMLFormatElement(&childBuf, "allocation", &allocAttrBuf, NULL);
+
if (mem->discard)
virBufferAddLit(&childBuf, "<discard/>\n");
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index b69abfa270..49c964e6e1 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2702,6 +2702,7 @@ struct _virDomainMemtune {
int source; /* enum virDomainMemorySource */
int access; /* enum virDomainMemoryAccess */
int allocation; /* enum virDomainMemoryAllocation */
+ unsigned int allocation_threads;
virTristateBool discard;
};
diff --git a/src/conf/schemas/domaincommon.rng b/src/conf/schemas/domaincommon.rng
index 9c1b64a644..34bccee2f5 100644
--- a/src/conf/schemas/domaincommon.rng
+++ b/src/conf/schemas/domaincommon.rng
@@ -740,12 +740,19 @@
</optional>
<optional>
<element name="allocation">
- <attribute name="mode">
- <choice>
- <value>immediate</value>
- <value>ondemand</value>
- </choice>
- </attribute>
+ <optional>
+ <attribute name="mode">
+ <choice>
+ <value>immediate</value>
+ <value>ondemand</value>
+ </choice>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="threads">
+ <ref name="unsignedInt"/>
+ </attribute>
+ </optional>
</element>
</optional>
<optional>
diff --git a/tests/qemuxml2argvdata/memfd-memory-numa.xml
b/tests/qemuxml2argvdata/memfd-memory-numa.xml
index 1ebcee8939..1ac87e3aef 100644
--- a/tests/qemuxml2argvdata/memfd-memory-numa.xml
+++ b/tests/qemuxml2argvdata/memfd-memory-numa.xml
@@ -10,7 +10,7 @@
</hugepages>
<source type='memfd'/>
<access mode='shared'/>
- <allocation mode='immediate'/>
+ <allocation mode='immediate' threads='8'/>
</memoryBacking>
<vcpu placement='static'>8</vcpu>
<numatune>
--
2.34.1
3:11 p.m.
New subject: [PATCH v2] conf: Introduce memory allocation threads
On Thu, Mar 24, 2022 at 12:16:01PM +0100, Michal Privoznik wrote:
Since its v5.0.0 release QEMU is capable of specifying number of
threads used to allocate memory. It defaults to 1, which may be
too low for humongous guests with gigantic pages.
In general, on QEMU cmd line level it is possible to use
different number of threads per each memory-backend-* object, in
practical terms it's not useful. Therefore, use <memoryBacking/>
to set guest wide value and let all memory devices 'inherit' it,
silently. IOW, don't introduce per device knob because that would
only complicate things for a little or no benefit.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Martin Kletzander <mkletzan(a)redhat.com>
911
days inactive
913
days old
15 comments
4 participants
participants (4)
-
Daniel P. Berrangé -
Martin Kletzander -
Michal Privoznik -
Michal Prívozník