[PATCH] Fix the dupliacated cpus used in different cells issue
Signed-off-by: Jing Qi --- docs/formatdomain.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 24611f0f09..f69957d8c3 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -1662,14 +1662,13 @@ ACPI Heterogeneous Memory Attribute Table ... - - - + + -- 2.32.0
[PATCH] Fix the dupliacated cpus used in different cells issue
Signed-off-by: Jing Qi --- docs/formatdomain.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index f69957d8c3..47b41d257e 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -1669,6 +1669,7 @@ ACPI Heterogeneous Memory Attribute Table + -- 2.32.0
Re: [PATCH v2 1/6] manpages: Document 'restrictive' mode for numatune
Thanks for your explanation. There is another update for the man page in patch 4/6 and that's the final version after the whole patch. I missed that. BR, Jing Qi On Fri, Dec 17, 2021 at 3:54 PM Michal Prívozník wrote: > On 12/17/21 02:35, Jing Qi wrote: > > Hi Michal, > > Seems there is a typo of 'restrictive' instead of 'strict' in the last > > line of updated content. Right? > > Actually, no. What this patch does is document the current state of > things. With current master, 'restrictive' is not allowed and only > 'strict' is (the fact it doesn't work really is addressed in later > patches in this series). Therefore, I think this patch is correct as is. > > But I see where you're coming from. In the end there will be only > 'restrictive' allowed. > > The reason I chose to do things separately is for easier cherry pick / > revert. Imagine at some point in future we will be able to tell QEMU to > migrate its own memory. Then we might want to revert patch 4/6 which > will leave us with: > > For a running domain, the mode can't be changed, and the nodeset can be > changed only if the domain was started with mode of either \`strict' or > \`restrictive'. > > > Hopefully, my explanation makes sense. > > Michal > > -- Thanks & Regards, Jing,Qi
Re: [PATCH v2 1/6] manpages: Document 'restrictive' mode for numatune
Hi Michal, Seems there is a typo of 'restrictive' instead of 'strict' in the last line of updated content. Right? Best Regards, Jing Qi On Fri, Dec 17, 2021 at 12:02 AM Michal Privoznik wrote: > While we document possibility of passing an integer from > virDomainNumatuneMemMode enum, we list string variants to only > the first three enum members. The fourth (and so far the last) > member is called 'restrictive' and thus should be documented. > > Signed-off-by: Michal Privoznik > --- > docs/manpages/virsh.rst | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst > index 611a6271cf..cd739c32c4 100644 > --- a/docs/manpages/virsh.rst > +++ b/docs/manpages/virsh.rst > @@ -3545,11 +3545,11 @@ Set or get a domain's numa parameters, > corresponding to the > element of domain XML. Without flags, the current settings are > displayed. > > -*mode* can be one of \`strict', \`interleave' and \`preferred' or any > -valid number from the virDomainNumatuneMemMode enum in case the daemon > -supports it. For a running domain, the mode can't be changed, and the > -nodeset can be changed only if the domain was started with a mode of > -\`strict'. > +*mode* can be one of \`strict', \`interleave', \`preferred' and > +\'restrictive' or any valid number from the virDomainNumatuneMemMode enum > +in case the daemon supports it. For a running domain, the mode can't be > +changed, and the nodeset can be changed only if the domain was started > with > +a mode of \`strict'. > > *nodeset* is a list of numa nodes used by the host for running the domain. > Its syntax is a comma separated list, with '-' for ranges and '^' for > -- > 2.32.0 > > -- Thanks & Regards, Jing,Qi
Re: [PATCH v5 05/16] qemu: Build command line for virtio-mem
Hi Michal, The domain xml is attached. Regards, Jing Qi On Wed, Sep 15, 2021 at 7:14 PM Michal Prívozník wrote: > On 9/14/21 3:05 PM, David Hildenbrand wrote: > > On 13.09.21 16:52, Michal Privoznik wrote: > >> Nothing special is happening here. All important changes were > >> done when for 'virtio-pmem' (adjusting the code to put virtio > >> memory on PCI bus, generating alias using > >> qemuDomainDeviceAliasIndex(). The only bit that might look > >> suspicious is no prealloc for virtio-mem. But if you think about > >> it, the whole purpose of this device is to change amount of > >> memory exposed to guest on the fly. There is no point in locking > >> the whole backend in memory. > > > > Do I understand correctly that we'll always try setting "reserve=off", > > and "prealloc=off"? That would be awesome :) > > prealloc=off would be set (almost) unconditionally for all > memory-backend-* objects that are associated with virtio-mem device. And > if QEMU is new enough to have .reserve attribute then reserve=off is set > too. > > > > > I do wonder if we want to warn or bail out if "priv->memPrealloc" is set > > but we are temporarily not able to support it -- as discussed, because > > virtio-mem in QEMU yet has to be taught about it. > > priv->memPrealloc might not be what you think it is. The fact whether > immediate allocation was requested is stored in def->mem.allocation; and > priv->memPrealloc is just there to track whether -mem-prealloc what > already put onto (paritally) generated cmd line and thus the rest of > generators must refrain from setting prealloc=on. > > Codewise speaking, if you'd look at qemuBuildCommandLine() (this is > where cmd line generation happens) then you'd see > qemuBuildMemCommandLine() being called first and only after that > qemuBuildMemoryDeviceCommandLine() being called second. > > The former is responsible for generating generic memory for guest (e.g. > -m XX -mem-prealloc -mem-path ... which is the old style, nowadays a > combination of -machine memory-backend= + -object memory-backend-* is > generated). > > Long story short, if priv->memPrealloc isn't true at this point, then > libvirt doesn't have to set prealloc=off explicitly, because off is the > default. > > > > > > FYI: QEMU will bail out if "reserve=off,prealloc=on" is set in > combination. > > Yeah, this combination should never happen. > > Michal > > -- Thanks & Regards, Jing,Qi pc bb508b28-d57b-44bd-9e9c-a134cef24b60 8388608 1179648 1179648 2 /machine hvm qemu64 destroy restart destroy /usr/bin/qemu-system-x86_64 0 2048 131072 0 2048 131072 131072 system_u:system_r:svirt_t:s0:c339,c343 system_u:object_r:svirt_image_t:s0:c339,c343 +107:+107 +107:+107
Re: [PATCH v5 05/16] qemu: Build command line for virtio-mem
Hi Michal,
I tried to test the virtio-mem with upstream version v7.7.0-136-g9b49c2c6d3
adding the current patch
(with qemu-6.1.0-7.fc36.x86_64) -
8388608
1179648
1179648
qemu64
...
0
2048
131072
0
2048
131072
The vm was started successfully and there was no "prealloc: true" in the
command line.
But I also found when was added in the
domain and the "virtio-mem" device was not added, the qemu command line
also didn't have "prealloc:true". Is this correct? This result is
different in "libvirt-7.6.0-3.module+el8.5.0+12510+80564ecf.x86_64" &
"qemu-kvm-6.0.0-29.module+el8.5.0+12386+43574bac.x86_64".
Best Regards,
Jing Qi
On Tue, Sep 14, 2021 at 9:07 PM David Hildenbrand wrote:
> On 13.09.21 16:52, Michal Privoznik wrote:
> > Nothing special is happening here. All important changes were
> > done when for 'virtio-pmem' (adjusting the code to put virtio
> > memory on PCI bus, generating alias using
> > qemuDomainDeviceAliasIndex(). The only bit that might look
> > suspicious is no prealloc for virtio-mem. But if you think about
> > it, the whole purpose of this device is to change amount of
> > memory exposed to guest on the fly. There is no point in locking
> > the whole backend in memory.
>
> Do I understand correctly that we'll always try setting "reserve=off",
> and "prealloc=off"? That would be awesome :)
>
> I do wonder if we want to warn or bail out if "priv->memPrealloc" is set
> but we are temporarily not able to support it -- as discussed, because
> virtio-mem in QEMU yet has to be taught about it.
>
> FYI: QEMU will bail out if "reserve=off,prealloc=on" is set in combination.
>
> >
> > Signed-off-by: Michal Privoznik
> > ---
> > src/qemu/qemu_alias.c | 9 +++-
> > src/qemu/qemu_command.c | 24 +--
> > ...mory-hotplug-virtio-mem.x86_64-latest.args | 41 +++
> > tests/qemuxml2argvtest.c | 1 +
> > 4 files changed, 70 insertions(+), 5 deletions(-)
> > create mode 100644
> tests/qemuxml2argvdata/memory-hotplug-virtio-mem.x86_64-latest.args
> >
> > diff --git a/src/qemu/qemu_alias.c b/src/qemu/qemu_alias.c
> > index 79e8953b2f..81a1e7eeed 100644
> > --- a/src/qemu/qemu_alias.c
> > +++ b/src/qemu/qemu_alias.c
> > @@ -475,8 +475,11 @@ qemuDeviceMemoryGetAliasID(virDomainDef *def,
> > size_t i;
> > int maxidx = 0;
> >
> > -/* virtio-pmem goes onto PCI bus and thus DIMM address is not valid
> */
> > -if (!oldAlias && mem->model != VIR_DOMAIN_MEMORY_MODEL_VIRTIO_PMEM)
> > +/* virtio-pmem and virtio-mem go onto PCI bus and thus DIMM address
> is not
> > + * valid */
> > +if (!oldAlias &&
> > +mem->model != VIR_DOMAIN_MEMORY_MODEL_VIRTIO_PMEM &&
> > +mem->model != VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM)
> > return mem->info.addr.dimm.slot;
> >
> > for (i = 0; i < def->nmems; i++) {
> > @@ -523,6 +526,8 @@ qemuAssignDeviceMemoryAlias(virDomainDef *def,
> > prefix = "virtiopmem";
> > break;
> > case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM:
> > +prefix = "virtiomem";
> > +break;
> > case VIR_DOMAIN_MEMORY_MODEL_NONE:
> > case VIR_DOMAIN_MEMORY_MODEL_LAST:
> > default:
> > diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> > index 594e5643b1..91f3094ac8 100644
> > --- a/src/qemu/qemu_command.c
> > +++ b/src/qemu/qemu_command.c
> > @@ -3136,9 +3136,19 @@ qemuBuildMemoryBackendProps(virJSONValue
> **backendProps,
> > virJSONValueObjectAdd(props,
> "b:x-use-canonical-path-for-ramblock-id", false, NULL) < 0)
> > return -1;
> >
> > -if (!priv->memPrealloc &&
> > -virJSONValueObjectAdd(props, "B:prealloc", prealloc, NULL) < 0)
> > -return -1;
> > +if (mem->model == VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM) {
> > +/* Explicitly disable prealloc for virtio-mem */
> > +if (priv->memPrealloc &&
> > +virJSONValueObjectAppendBoolean(props, "prealloc", 0) < 0)
> > +return -1;
> > +if (virQEMUCapsGet(priv->qemuCaps,
> QEMU_CAPS_MEMORY_BACKEND_RESERVE) &&
> > +virJSONValueObjectAppendBoolean(props, "reserve&quo
Re: [PATCH v2 1/1] qemu: add support for max-ram-below-4g option
hi ,
I used libvirt upstream code version v7.3.0-135-gc6989ed929 and applied the
patch. It failed to compile the code with below errors, can you please
check them?
../src/conf/domain_conf.c: In function ‘virDomainIOMMUDefCheckABIStability’:
../src/conf/domain_conf.c:22064:12: error: ‘virDomainIOMMUDef’ {aka ‘struct
_virDomainIOMMUDef’} has no member named ‘mem’
22064 | if (src->mem.max_ram_below_4g != dst->mem.max_ram_below_4g) {
|^~
../src/conf/domain_conf.c:22064:41: error: ‘virDomainIOMMUDef’ {aka ‘struct
_virDomainIOMMUDef’} has no member named ‘mem’
22064 | if (src->mem.max_ram_below_4g != dst->mem.max_ram_below_4g) {
| ^~
In file included from ../src/conf/domain_conf.c:31:
../src/conf/domain_conf.c:22068:27: error: ‘virDomainIOMMUDef’ {aka ‘struct
_virDomainIOMMUDef’} has no member named ‘mem’
22068 |dst->mem.max_ram_below_4g,
| ^~
../src/util/virerror.h:177:50: note: in definition of macro ‘virReportError’
177 | __FUNCTION__, __LINE__, __VA_ARGS__)
| ^~~
../src/conf/domain_conf.c:22069:27: error: ‘virDomainIOMMUDef’ {aka ‘struct
_virDomainIOMMUDef’} has no member named ‘mem’
22069 |src->mem.max_ram_below_4g);
| ^~
../src/util/virerror.h:177:50: note: in definition of macro ‘virReportError’
177 | __FUNCTION__, __LINE__, __VA_ARGS__)
| ^~~~~~~
Thanks,
Jing Qi
On Thu, May 6, 2021 at 4:29 PM Zhiyong Ye wrote:
> The 'below4g' attribute added in 'memory' element can be used to specify
> the low memory area, which allows to get a larger PCI I/O window below
> 4G when reduce it to a smaller value, and when raise value allows legacy
> non-PAE guests to have as much memory as possible in the 32bit address
> space below 4G. It does not share the 'unit' parameter with the actual
> memory size and its unit defaults to "KiB".
>
> Signed-off-by: Zhiyong Ye
> Signed-off-by: zhenwei pi
> Signed-off-by: zhangruien
> ---
> docs/formatdomain.rst | 10 ++--
> docs/schemas/domaincommon.rng | 5
> src/conf/domain_conf.c | 15
> src/conf/domain_conf.h | 3 +++
> src/conf/domain_validate.c | 13 ++
> src/qemu/qemu_command.c | 4
> tests/qemuxml2argvdata/memory-below4g.args | 29 ++
> tests/qemuxml2argvdata/memory-below4g.xml | 26
> tests/qemuxml2argvtest.c| 1 +
> tests/qemuxml2xmloutdata/memory-below4g.xml | 37
> +
> tests/qemuxml2xmltest.c | 1 +
> 11 files changed, 142 insertions(+), 2 deletions(-)
> create mode 100644 tests/qemuxml2argvdata/memory-below4g.args
> create mode 100644 tests/qemuxml2argvdata/memory-below4g.xml
> create mode 100644 tests/qemuxml2xmloutdata/memory-below4g.xml
>
> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
> index fa5c14febc..a71a716f5b 100644
> --- a/docs/formatdomain.rst
> +++ b/docs/formatdomain.rst
> @@ -940,8 +940,14 @@ Memory Allocation
> `NUMA <#elementsCPU>`__ is configured for the guest the ``memory``
> element
> can be omitted. In the case of crash, optional attribute ``dumpCore``
> can be
> used to control whether the guest memory should be included in the
> generated
> - coredump or not (values "on", "off"). ``unit`` :since:`since 0.9.11` ,
> - ``dumpCore`` :since:`since 0.10.2 (QEMU only)`
> + coredump or not (values "on", "off"). Besides, the optional ``below4g``
> + attribute can be used to specify the low memory area, which allows to
> get a
> + larger PCI I/O window below 4G when reduce it to a smaller value, and
> when
> + raise value allows legacy non-PAE guests to have as much memory as
> possible
> + in the 32bit address space below 4G. It does not share the ``unit``
> parameter
> + with the actual memory size and its unit defaults to "KiB". ``unit`` :
> + since:`since 0.9.11` , ``dumpCore`` : since:`since 0.10.2 (QEMU only)`,
> + ``below4g`` :since:`since 7.3.0 (QEMU only)`.
> ``maxMemory``
> The run time maximum memory allocation of the guest. The initial memory
> specified by either the element or the NUMA cell size
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index a2e5c50c1d..8f2ac1ad33 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -6
Re: [PATCH v3 RESEND for v7.4.0 00/14] Introduce virtio-mem model
Tested with libvirt v7.2.0-381-g3c3c55be66 and qemu-5.2.0-0.7.rc2.fc34.x86_64 S1. Without hugepage 1.Start domain with virtio-mem device, and check the value of is the total memory number including virtio-mem device. # virsh start pc_test 2. Hot plug a virtio-mem device, the values of memory & currentMemory are refreshed accordingly. # cat mem.xml 0 2048 131072 0 2048 131072 131072 #virsh attach-device pc_test mem.xml 3. Updated the requested size, and it's changed as expected from the output of "virsh dumpxml " # virsh update-memory-device pc_test --alias virtiomem1 --requested-size 100MiB S2. With below hugepage configuration, tested above 3 steps again, and all steps worked. S3. Hot plug virtio-pmem and the value of is updated accordingly. /tmp/nvdimm 131072 128 # virsh attach-device pc_test pmem.xml Device attached successfully #virsh dumpxml pc_test ... -- Tested-by Jing Qi On Fri, Apr 23, 2021 at 9:25 PM Michal Privoznik wrote: > This is a rebased version of v3 I've sent about a month ago: > > https://listman.redhat.com/archives/libvir-list/2021-March/msg00823.html > > v2 here: > > https://listman.redhat.com/archives/libvir-list/2021-February/msg00961.html > > My intent is to merge these only after the upcoming release so that we > have the biggest test window possible. > > diff to v2: > - Dropped code that forbade use of virtio-mem and memballoon at the same > time; > - This meant that I had to adjust memory accounting, > qemuDomainSetMemoryFlags() - see patches 11/15 and 12/15 which are new. > - Fixed small nits raised by Peter in his review of v2 > > > Michal Prívozník (14): > virhostmem: Introduce virHostMemGetTHPSize() > qemu_process: Deduplicate code in qemuProcessNeedHugepagesPath() > qemu_process: Drop needless check in > qemuProcessNeedMemoryBackingPath() > qemu_capabilities: Introduce QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI > conf: Introduce virtio-mem model > qemu: Build command line for virtio-mem > qemu: Wire up live update > qemu: Wire up MEMORY_DEVICE_SIZE_CHANGE event > qemu: Refresh the actual size of virtio-mem on monitor reconnect > qemu: Account for both memballoon and virtio-mem > qemuDomainSetMemoryFlags: Take virtio-mem into consideration > virsh: Introduce update-memory-device command > news: document recent virtio memory addition > kbase: Document virtio-mem > > NEWS.rst | 16 ++ > docs/formatdomain.rst | 45 +++- > docs/kbase/index.rst | 4 + > docs/kbase/memorydevices.rst | 150 +++ > docs/kbase/meson.build| 1 + > docs/manpages/virsh.rst | 30 +++ > docs/schemas/domaincommon.rng | 16 ++ > examples/c/misc/event-test.c | 17 ++ > include/libvirt/libvirt-domain.h | 23 ++ > src/conf/domain_conf.c| 115 - > src/conf/domain_conf.h| 15 ++ > src/conf/domain_event.c | 84 +++ > src/conf/domain_event.h | 10 + > src/conf/domain_validate.c| 39 +++ > src/libvirt_private.syms | 5 + > src/qemu/qemu_alias.c | 10 +- > src/qemu/qemu_capabilities.c | 2 + > src/qemu/qemu_capabilities.h | 1 + > src/qemu/qemu_command.c | 13 +- > src/qemu/qemu_domain.c| 50 +++- > src/qemu/qemu_domain.h| 1 + > src/qemu/qemu_domain_address.c| 38 ++- > src/qemu/qemu_driver.c| 233 +- > src/qemu/qemu_hotplug.c | 18 ++ > src/qemu/qemu_hotplug.h | 5 + > src/qemu/qemu_monitor.c | 37 +++ > src/qemu/qemu_monitor.h | 28 +++ > src/qemu/qemu_monitor_json.c | 97 ++-- > src/qemu/qemu_monitor_json.h | 5 + > src/qemu/qemu_process.c | 118 - > src/qemu/qemu_validate.c | 8 + > src/remote/remote_daemon_dispatch.c | 30 +++ > src/remote/remote_driver.c| 32 +++ > src/remote/remote_protocol.x | 14 +- > src/remote_protocol-structs | 7 + > src/security/security_apparmor.c | 1 + > src/security/security_dac.c |
Re: [PATCH v3 09/14] qemu: Refresh the actual size of virtio-mem on monitor reconnect
Tested the patch with libvirt v7.2.0-381-g3c3c55be66 &
qemu-kvm-5.2.0-0.7.rc2.fc34.x86_64
S1: Start domain with virtio-mem device
# virsh start pc_test
# virsh dumpxml pc_test
pc_test
927da985-2937-4dfe-ac13-be723293e0d9
6291456
1179648
1179648
...
0
2048
131072
0
2048
131072
131072
..
2. Hot plug a virtio-mem device, the values of memory & currentMemory are
updated accordingly.
# cat mem.xml
0
2048
131072
0
2048
131072
131072
#virsh attach-device pc_test mem.xml
Device attached successfully
# virsh dumpxml pc_test
1310720
1310720
...
0
2048
131072
0
2048
131072
131072
0
2048
131072
0
2048
131072
131072
3. Updated the requested size, it's changed as expected.
# virsh update-memory-device pc_test --alias virtiomem1 --requested-size
100MiB
# virsh dumpxml pc_test
1310720
1282048
...
0
2048
131072
0
2048
102400
102400
S2: From the docs, "virtio-pmem" works also.
# cat pmem.xml
/tmp/nvdimm
131072
128
# virsh attach-device pc_test pmem.xml
Device attached successfully
#virsh dumpxml pc_test
1441792
1282048
Question:
But seems it don't support element , and if add element,
below errors are prompted -
error: Failed to attach device from pmem
error: unsupported configuration: virtio-pmem does not support NUMA nodes
Since the element is supported by nvdimm & virtio-mem, can you help
to confirm if it's as expected? @Michal Privoznik
Thanks,
Jing Qi
On Fri, Apr 23, 2021 at 9:26 PM Michal Privoznik
wrote:
> If the QEMU driver restarts it loses the track of the actual size
> of virtio-mem (because it's runtime type of information and thus
> not stored in XML) and therefore, we have to refresh it when
> reconnecting to the domain monitor.
>
> Signed-off-by: Michal Privoznik
> ---
> src/qemu/qemu_domain.c | 37 +++
> src/qemu/qemu_monitor.h | 3 ++
> src/qemu/qemu_monitor_json.c | 58 ++--
> src/qemu/qemu_process.c | 3 ++
> 4 files changed, 73 insertions(+), 28 deletions(-)
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 226e1d9b79..3c17d8704a 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -8278,9 +8278,21 @@ qemuDomainUpdateMemoryDeviceInfo(virQEMUDriver
> *driver,
> return -1;
> }
>
> -/* if qemu doesn't support the info request, just carry on */
> -if (rc == -2)
> +/* If qemu doesn't support the info request, just carry on, unless we
> + * really need it. */
> +if (rc == -2) {
> +for (i = 0; i < vm->def->nmems; i++) {
> +virDomainMemoryDef *mem = vm->def->mems[i];
> +
> +if (mem->model == VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM) {
> +virReportError(VIR_ERR_INTERNAL_ERROR, "%s",
> + _("qemu did not return info on vitio-mem
> device"));
> +return -1;
> +}
> +}
> +
> return 0;
> +}
>
> if (rc < 0)
> return -1;
> @@ -8295,9 +8307,24 @@ qemuDomainUpdateMemoryDeviceInfo(virQEMUDriver
> *driver,
> if (!(dimm = virHashLookup(meminfo, mem->info.alias)))
> continue;
>
> -mem->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DIMM;
> -mem->info.addr.dimm.slot = dimm->slot;
> -mem->info.addr.dimm.base = dimm->address;
> +switch (mem->model) {
> +case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_MEM:
> +mem->actualsize = VIR_DIV_UP(dimm->size, 1024);
> +break;
> +
> +case VIR_DOMAIN_MEMORY_MODEL_DIMM:
> +case VIR_DOMAIN_MEMORY_MODEL_NVDIMM:
> +mem->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DIMM;
> +mem->info.addr.dimm.slot = dimm->slot;
> +mem->info.addr.dimm.base = dimm->address;
> +break;
> +
> +case VIR_DOMAIN_MEMORY_MODEL_VIRTIO_PMEM:
> +case VIR_DOMAIN_MEMORY_MODEL_NONE:
> +case VIR_DOMAIN_MEMORY_MODEL_LAST:
> +/* nada */
> +break;
> +}
> }
>
> virHashFree(meminfo);
> diff --git a/src/qemu/qemu_m
Re: [libvirt][PATCH v5 3/3] qemu: add parser and formatter for 'restrictive' mode in numatune
ess.h:24,
from ../src/qemu/qemu_process.c:41:
../src/conf/numa_conf.h:104:45: note: expected ‘virDomainNuma *’ {aka
‘struct _virDomainNuma *’} but argument is of type ‘int’
104 | int virDomainNumatuneGetMode(virDomainNuma *numatune,
| ~~~^~~~
../src/qemu/qemu_process.c:2751:61: error: passing argument 1 of
‘virDomainNumatuneMaybeFormatNodeset’ makes pointer from integer without a
cast [-Werror=int-conversion]
2751 | if
(virDomainNumatuneMaybeFormatNodeset(numatune,
| ^~~~
| |
| int
In file included from ../src/conf/cpu_conf.h:27,
from ../src/conf/capabilities.h:27,
from ../src/qemu/qemu_conf.h:28,
from ../src/qemu/qemu_process.h:24,
from ../src/qemu/qemu_process.c:41:
../src/conf/numa_conf.h:155:56: note: expected ‘virDomainNuma *’ {aka
‘struct _virDomainNuma *’} but argument is of type ‘int’
155 | int virDomainNumatuneMaybeFormatNodeset(virDomainNuma *numatune,
| ~~~^~~~
cc1: all warnings being treated as errors
Thanks,
Jing Qi
On Tue, Apr 13, 2021 at 2:37 PM Luyao Zhong wrote:
> Reviewed-by: Daniel Henrique Barboza
> Signed-off-by: Luyao Zhong
> ---
> include/libvirt/libvirt-domain.h | 1 +
> src/conf/numa_conf.c | 9
> src/qemu/qemu_command.c | 6 ++-
> src/qemu/qemu_process.c | 27
> src/util/virnuma.c| 3 ++
> .../numatune-memnode-invalid-mode.err | 1 +
> .../numatune-memnode-invalid-mode.xml | 33 +++
> ...emnode-restrictive-mode.x86_64-latest.args | 38 +
> .../numatune-memnode-restrictive-mode.xml | 33 +++
> tests/qemuxml2argvtest.c | 2 +
> ...memnode-restrictive-mode.x86_64-latest.xml | 41 +++
> tests/qemuxml2xmltest.c | 1 +
> 12 files changed, 194 insertions(+), 1 deletion(-)
> create mode 100644
> tests/qemuxml2argvdata/numatune-memnode-invalid-mode.err
> create mode 100644
> tests/qemuxml2argvdata/numatune-memnode-invalid-mode.xml
> create mode 100644
> tests/qemuxml2argvdata/numatune-memnode-restrictive-mode.x86_64-latest.args
> create mode 100644
> tests/qemuxml2argvdata/numatune-memnode-restrictive-mode.xml
> create mode 100644
> tests/qemuxml2xmloutdata/numatune-memnode-restrictive-mode.x86_64-latest.xml
>
> diff --git a/include/libvirt/libvirt-domain.h
> b/include/libvirt/libvirt-domain.h
> index 03c119fe26..e99bfb7654 100644
> --- a/include/libvirt/libvirt-domain.h
> +++ b/include/libvirt/libvirt-domain.h
> @@ -1527,6 +1527,7 @@ typedef enum {
> VIR_DOMAIN_NUMATUNE_MEM_STRICT = 0,
> VIR_DOMAIN_NUMATUNE_MEM_PREFERRED = 1,
> VIR_DOMAIN_NUMATUNE_MEM_INTERLEAVE = 2,
> +VIR_DOMAIN_NUMATUNE_MEM_RESTRICTIVE = 3,
>
> # ifdef VIR_ENUM_SENTINELS
> VIR_DOMAIN_NUMATUNE_MEM_LAST /* This constant is subject to change */
> diff --git a/src/conf/numa_conf.c b/src/conf/numa_conf.c
> index 64b93fd7d1..11093531b5 100644
> --- a/src/conf/numa_conf.c
> +++ b/src/conf/numa_conf.c
> @@ -43,6 +43,7 @@ VIR_ENUM_IMPL(virDomainNumatuneMemMode,
>"strict",
>"preferred",
>"interleave",
> + "restrictive",
> );
>
> VIR_ENUM_IMPL(virDomainNumatunePlacement,
> @@ -234,6 +235,14 @@ virDomainNumatuneNodeParseXML(virDomainNumaPtr numa,
> _("Invalid mode attribute in memnode
> element"));
> goto cleanup;
> }
> +
> +if (numa->memory.mode == VIR_DOMAIN_NUMATUNE_MEM_RESTRICTIVE
> &&
> +mode != VIR_DOMAIN_NUMATUNE_MEM_RESTRICTIVE) {
> +virReportError(VIR_ERR_XML_ERROR, "%s",
> + _("'restrictive' mode is required in
> memnode element "
> + "when mode is 'restrictive' in memory
> element"));
> +goto cleanup;
> +}
> VIR_FREE(tmp);
> mem_node->mode = mode;
> }
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index 45eb0dc976..a6a1717115 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -175,6 +175,7 @@ VIR_ENUM_IMPL(qemuNumaPolicy,
>"bind",
&g
Re: [PATCH 00/10] Introduce virtio-mem model
Thanks Michal. I checked the virtio_mem module in the host last time. I tried a new guest image with virtio_mem module and start the domain , then the value of actual can be set correctly. Jing Qi On Thu, Feb 4, 2021 at 4:52 PM Michal Privoznik wrote: > On 2/4/21 3:33 AM, Jing Qi wrote: > > Michal, > > I checked the virtio_mem module and it's loaded - > > > > lsmod |grep virtio_mem > > virtio_mem 32768 0 > > > > And I can't make the actual value change to non-zerio. > > -> virsh update-memory pc --requested-size 256M > > or > > ->virsh setmem pc 1000M > > This is unrelated. 'setmem' modifies balloon not virtio-mem-pci device. > > > > > > > > > 524288 > > 0 > > 2048 > > 262144 > > 0 > > > > > > > function='0x0'/> > > > > Any other suggestions ? > > > Is there something in the guest dmesg? This is what I get: > > virsh update-memory-device gentoo --alias ua-virtiomem 256M > > [ 17.619060] virtio_mem virtio3: plugged size: 0x0 > [ 17.619062] virtio_mem virtio3: requested size: 0x1000 > [ 17.653072] Built 4 zonelists, mobility grouping on. Total pages: > 2065850 > [ 17.653074] Policy zone: Normal > > > And I can see actual size updated: > > > > 2048 > > > 4194304 > 0 > 2048 > 262144 > 262144 > > > function='0x0'/> > > > Maybe David knows the answer. > > Michal > > -- Thanks & Regards, Jing,Qi
Re: [PATCH 00/10] Introduce virtio-mem model
Michal, I checked the virtio_mem module and it's loaded - lsmod |grep virtio_mem virtio_mem 32768 0 And I can't make the actual value change to non-zerio. -> virsh update-memory pc --requested-size 256M or ->virsh setmem pc 1000M 524288 0 2048 262144 0 Any other suggestions ? > This is a bummer. What this represents is the actual value of membaloon. > Yes and no. It shows that we need because guest might ignore > request to change the requested size. What you're probably experiencing > is that you haven't loaded virtio_mem module and thus the virtio-mem > device is ignoring requests for change (well, kernel is ignoring them, > whatever). On Thu, Feb 4, 2021 at 12:27 AM Michal Privoznik wrote: > On 2/3/21 7:11 AM, Jing Qi wrote: > > I did some test for virtio-mem with libvirt upstream version > > v7.0.0-153-g5ea3ecd07d > > & qemu-kvm-5.2.0-0.7.rc2.fc34.x86_64 > > > > S1. Start domain with memory device > > > > 1. Domain configuration- > > 10485760 > >1572864 > >1572864 > > ... > > > > > > > > > > > > ... > > > > > > 524288 > > 0 > > 2048 > > 393216 > > > > > function='0x0'/> > > > > #virsh start pc > > Domain 'pc' started > > > > 2. The domain is started and check mem status, the actual size is > "1048576" > > #virsh dommemstat pc > > actual 1048576 > > This is a bummer. What this represents is the actual value of membaloon. > > > swap_in 0 > > swap_out 0 > > major_fault 257 > > minor_fault 130540 > > unused 604064 > > available 761328 > > usable 578428 > > last_update 1612325471 > > disk_caches 49632 > > hugetlb_pgalloc 0 > > hugetlb_pgfail 0 > > rss 460260 > > > > 3. Then, check the active xml - > > # virsh dumpxml pc > > ... > > 1572864 > >1048576 > > > > > > > > 524288 > > 0 > > 2048 > > 393216 > > 0 > > > > > > > function='0x0'/> > > > > > > Question1 : the value of actual is "0". Is it expected? > > Yes and no. It shows that we need because guest might ignore > request to change the requested size. What you're probably experiencing > is that you haven't loaded virtio_mem module and thus the virtio-mem > device is ignoring requests for change (well, kernel is ignoring them, > whatever). > > > > > S2. Also, tried to use hugepage to start the domain - > > > > > > > > 524288 > > 0 > > 2048 > > 393216 > > 0 > > > > > > > function='0x0'/> > > > > > > #virsh start pc > > error: Failed to start domain 'pc' > > error: internal error: process exited while connecting to monitor: > > 2021-02-03T05:50:33.157836Z qemu-system-x86_64: -object > > > memory-backend-file,id=memvirtiomem0,mem-path=/dev/hugepages/libvirt/qemu/9-pc,size=536870912,host-nodes=0,policy=bind: > > can't open backing store /dev/hugepages/libvirt/qemu/9-pc for guest RAM: > > Permission denied > > > > Question 2: any bug here? > > Ah, good catch! I'll fix this in v2. > > Michal > > -- Thanks & Regards, Jing,Qi
Re: [PATCH 00/10] Introduce virtio-mem model
I did some test for virtio-mem with libvirt upstream version v7.0.0-153-g5ea3ecd07d & qemu-kvm-5.2.0-0.7.rc2.fc34.x86_64 S1. Start domain with memory device 1. Domain configuration- 10485760 1572864 1572864 ... ... 524288 0 2048 393216 #virsh start pc Domain 'pc' started 2. The domain is started and check mem status, the actual size is "1048576" #virsh dommemstat pc actual 1048576 swap_in 0 swap_out 0 major_fault 257 minor_fault 130540 unused 604064 available 761328 usable 578428 last_update 1612325471 disk_caches 49632 hugetlb_pgalloc 0 hugetlb_pgfail 0 rss 460260 3. Then, check the active xml - # virsh dumpxml pc ... 1572864 1048576 524288 0 2048 393216 0 Question1 : the value of actual is "0". Is it expected? S2. Also, tried to use hugepage to start the domain - 524288 0 2048 393216 0 #virsh start pc error: Failed to start domain 'pc' error: internal error: process exited while connecting to monitor: 2021-02-03T05:50:33.157836Z qemu-system-x86_64: -object memory-backend-file,id=memvirtiomem0,mem-path=/dev/hugepages/libvirt/qemu/9-pc,size=536870912,host-nodes=0,policy=bind: can't open backing store /dev/hugepages/libvirt/qemu/9-pc for guest RAM: Permission denied Question 2: any bug here? On Tue, Feb 2, 2021 at 9:44 PM Peter Krempa wrote: > On Fri, Jan 22, 2021 at 13:50:21 +0100, Michal Privoznik wrote: > > Technically, this is another version of: > > > > https://www.redhat.com/archives/libvir-list/2020-December/msg00199.html > > > > But since virtio-pmem part is pushed now, I've reworked virtio-mem a bit > > and sending it as a new series. > > > > For curious ones, David summarized behaviour well when implementing > > virtio-mem support in kernel: > > > > https://lwn.net/Articles/755423/ > > > > For less curious ones: > > > > # virsh update-memory $dom --requested-size 4G > > > > adds additional 4GiB of RAM to guest; > > > > # virsh update-memory $dom --requested-size 0 > > > > removes those 4GiB added earlier. > > > > Patches are also available on my GitLab: > > > > https://gitlab.com/MichalPrivoznik/libvirt/-/tree/virtio_mem_v3 > > > > Patches 1-7,9-10 (but observe some individual comments, including > the rename of the virsh commands): > > Reviewed-by: Peter Krempa > > Patch 8 has severe semantic problems. > > -- Thanks & Regards, Jing,Qi
