Re: [PATCH v2 1/4] conf: Introduce dynamicMemslots attribute for virtio-mem

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(a)redhat.com&gt; >>> --- >>> 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.

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.