On 05.01.24 14:58, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 14:34:53 +0100, David Hildenbrand wrote:
On 05.01.24 13:40, Peter Krempa wrote:
On Fri, Jan 05, 2024 at 13:33:32 +0100, Michal Privoznik wrote:
Introduced in v8.2.0-rc0~74^2~2, QEMU now allows setting
.dynamic-memslots attribute for virtio-mem-pci devices. When
turned on, it allows memory exposed to guest to be split into
multiple memslots and thus smaller memory footprint (see the
original commit for detailed explanation).
Therefore, introduce new <target/> attribute which will control
that QEMU knob.
Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx>
---
docs/formatdomain.rst | 6 ++++++
src/conf/domain_conf.c | 18 +++++++++++++++++-
src/conf/domain_conf.h | 1 +
src/conf/schemas/domaincommon.rng | 5 +++++
.../memory-hotplug-virtio-mem.xml | 2 +-
5 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 96e03a3807..57974de9f4 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -8395,6 +8395,12 @@ Example: usage of the memory devices
The ``node`` subelement configures the guest NUMA node to attach the memory
to. The element shall be used only if the guest has NUMA nodes configured.
+ For ``virtio-mem`` optional attribute ``dynamicMemslots`` can be specified
+ (accepted values "yes"/"no") which allows hypervisor to spread memory into
+ multiple memory slots (allocate them dynamically based on the amount of
+ memory exposed to the guest), resulting in smaller memory footprint.
+ :since:`Since 10.0.0 and QEMU 8.2.0`
Is there any drawback in always setting 'yes'? (modulo cases when it
would not work, obviously)
In combination with some vhost devices (especially vhost-user), starting
QEMU might fail until these devices support more memslots. There is ongoing
work to improve these vhost-user devices.
To make these setups temporarily work, one would have to manually set
"dynamic-memslots=off" here, which is not too bad I guess.
Besides that, I don't think there is a real drawback -- there are mostly
only benefits of having it :)
I'm actually hoping that we can default-enable it, at least in RHEL soon.
Maybe we can default-enable it right away and document that vhost-user
devices will require it to be manually disabled until they support more
memslots?
This series is very specifically adding it only for virtio-mem, which
AFAIK doesn't have any vhost-user variant, thus having this as a
configurable knob is almost pointless.
No, that problem is the combination. Assume you have VM with both
virtio-mem to hotplug memory and virtio-user-fs+virtiofsd.
The memory that virtio-mem provides has to be usable by
virtio-user-fs+virtiofsd. Therefore, we have to map that shared memory
(provided by virtio-mem) into the virtiofsd process.
However, virtiofsd only supports 32 memslots and virito-mem wants to use
up to 256 (like having 256 DIMMs). virtiofsd support is in the works but
not upstream yet.
So if you start a vm with
-device virtio-mem-pci,dynamic-memslots=on,...
-device virtio-user-fs-pci, ...
QEMU might reject to start if the virtio-user-fs-pci backend has
insufficient memory slots.
In that case (and only then), we want to disable dynamic memslots.
Without the virtio-user complication (that I hate), this wouldn't even
be a configurable toggle.
The only real reason to have it is to ensure ABI compatibility between
configs and when migrating, but ideally should be completely hidden if
there's no need for users to disable it. (libvirt can do that but it's a
bit less straightforward)
Ideally for any kind of options which are ABI incompatible but there's
no real reason for users to disable them, qemu should add them as a
machine type property (to ensure ABI stability) and just enable them by
default.
QEMU would need to bind them to a machine type anyways once changing the
default.
Yes.
--
Cheers,
David / dhildenb
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
