qemu/include
Maciej S. Szmigiero 0d9e8c0b67 Add Hyper-V Dynamic Memory Protocol driver (hv-balloon) base
This driver is like virtio-balloon on steroids: it allows both changing the
guest memory allocation via ballooning and (in the next patch) inserting
pieces of extra RAM into it on demand from a provided memory backend.

The actual resizing is done via ballooning interface (for example, via
the "balloon" HMP command).
This includes resizing the guest past its boot size - that is, hot-adding
additional memory in granularity limited only by the guest alignment
requirements, as provided by the next patch.

In contrast with ACPI DIMM hotplug where one can only request to unplug a
whole DIMM stick this driver allows removing memory from guest in single
page (4k) units via ballooning.

After a VM reboot the guest is back to its original (boot) size.

In the future, the guest boot memory size might be changed on reboot
instead, taking into account the effective size that VM had before that
reboot (much like Hyper-V does).

For performance reasons, the guest-released memory is tracked in a few
range trees, as a series of (start, count) ranges.
Each time a new page range is inserted into such tree its neighbors are
checked as candidates for possible merging with it.

Besides performance reasons, the Dynamic Memory protocol itself uses page
ranges as the data structure in its messages, so relevant pages need to be
merged into such ranges anyway.

One has to be careful when tracking the guest-released pages, since the
guest can maliciously report returning pages outside its current address
space, which later clash with the address range of newly added memory.
Similarly, the guest can report freeing the same page twice.

The above design results in much better ballooning performance than when
using virtio-balloon with the same guest: 230 GB / minute with this driver
versus 70 GB / minute with virtio-balloon.

During a ballooning operation most of time is spent waiting for the guest
to come up with newly freed page ranges, processing the received ranges on
the host side (in QEMU and KVM) is nearly instantaneous.

The unballoon operation is also pretty much instantaneous:
thanks to the merging of the ballooned out page ranges 200 GB of memory can
be returned to the guest in about 1 second.
With virtio-balloon this operation takes about 2.5 minutes.

These tests were done against a Windows Server 2019 guest running on a
Xeon E5-2699, after dirtying the whole memory inside guest before each
balloon operation.

Using a range tree instead of a bitmap to track the removed memory also
means that the solution scales well with the guest size: even a 1 TB range
takes just a few bytes of such metadata.

Since the required GTree operations aren't present in every Glib version
a check for them was added to the meson build script, together with new
"--enable-hv-balloon" and "--disable-hv-balloon" configure arguments.
If these GTree operations are missing in the system's Glib version this
driver will be skipped during QEMU build.

An optional "status-report=on" device parameter requests memory status
events from the guest (typically sent every second), which allow the host
to learn both the guest memory available and the guest memory in use
counts.

Following commits will add support for their external emission as
"HV_BALLOON_STATUS_REPORT" QMP events.

The driver is named hv-balloon since the Linux kernel client driver for
the Dynamic Memory Protocol is named as such and to follow the naming
pattern established by the virtio-balloon driver.
The whole protocol runs over Hyper-V VMBus.

The driver was tested against Windows Server 2012 R2, Windows Server 2016
and Windows Server 2019 guests and obeys the guest alignment requirements
reported to the host via DM_CAPABILITIES_REPORT message.

Acked-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
2023-11-06 14:08:10 +01:00
..
authz
block blockjob: query driver-specific info via a new 'query' driver method 2023-10-31 18:20:29 +01:00
chardev include/: spelling fixes 2023-09-08 13:08:52 +03:00
crypto crypto: Add generic 64-bit carry-less multiply routine 2023-09-15 13:57:00 +00:00
disas disas: Change type of disassemble_info.target_info to pointer 2023-06-13 17:25:47 +10:00
exec tcg: Drop unused tcg_temp_free define 2023-10-23 14:45:46 -07:00
fpu fpu: Add conversions between bfloat16 and [u]int8 2023-09-16 14:57:15 +00:00
gdbstub gdbstub: replace exit calls with proper shutdown for softmmu 2023-10-12 12:36:37 +10:00
hw Add Hyper-V Dynamic Memory Protocol driver (hv-balloon) base 2023-11-06 14:08:10 +01:00
io io: follow coroutine AioContext in qio_channel_yield() 2023-09-07 20:32:11 -05:00
libdecnumber
migration migration: per-mode blockers 2023-11-01 16:13:59 +01:00
monitor monitor: add more *_locked() functions 2023-05-25 10:18:33 +02:00
net net/net: Clean up global variable shadowing 2023-10-06 13:27:43 +02:00
qapi qobject atomics osdep: Make a few macros more hygienic 2023-09-29 08:13:57 +02:00
qemu util/defer-call: move defer_call() to util/ 2023-10-31 15:41:42 +01:00
qom qom/object_interfaces: Clean up global variable shadowing 2023-10-06 13:27:48 +02:00
scsi hw/ufs: Support for UFS logical unit 2023-09-07 14:01:29 -04:00
semihosting * util/log: re-allow switching away from stderr log file 2023-10-09 10:11:18 -04:00
standard-headers linux-headers: Update to Linux v6.6-rc1 2023-09-12 11:34:56 +02:00
sysemu util/defer-call: move defer_call() to util/ 2023-10-31 15:41:42 +01:00
tcg tcg: Export tcg_gen_ext_{i32,i64,tl} 2023-10-22 16:32:28 -07:00
ui ui/input: Constify QemuInputHandler structure 2023-10-19 23:13:28 +02:00
user bulk: Do not declare function prototypes using 'extern' keyword 2023-08-31 19:47:43 +02:00
elf.h util: spelling fixes 2023-08-31 19:47:43 +02:00
glib-compat.h
qemu-io.h
qemu-main.h