This repository was archived by the owner on May 12, 2021. It is now read-only.

Description
Description of problem
There are 2 phases in Memory Hotplug. 1) Physical Memory Hotplug phase. 2) Logical Memory Hotplug phase.
The First phase is to communicate hardware/firmware and make/erase environment for hotplugged memory.
If firmware supports notification of connection of new memory to OS, this phase is triggered automatically. ACPI can notify this event. This also what kata supports, memory hotplug via acpi-driven.
But if not, there is another option, probe operation by hand.
And since memory hotplug via acpi is missing on qemu-system-aarch64, we hope to support the other probe solution.
the whole detailed info about probe interface could be found here.
This whole implementation of memory hotplug via probe interface is divided into two phases, the first is to check if guest kernel is capable of memory hot-add via probe interface, which is located at /sys/devices/system/memory/probe.
The second is let kata-agent tell guest kernel the physical address of new memory block.
echo start_address_of_new_memory > /sys/devices/system/memory/probe
Expected result
root@entos-thunderx2-desktop:~# docker run --runtime kata-runtime -it --rm -m 3G ubuntu
WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
root@9ebdb553ba9b:/# lsmem
RANGE SIZE STATE REMOVABLE BLOCK
0x0000000040000000-0x00000000bfffffff 2G online no 1-2
0x0000020000000000-0x00000200bfffffff 3G online no 2048-2050
Memory block size: 1G
Total online memory: 5G
Total offline memory: 0B
root@9ebdb553ba9b:/# ls /sys/devices/system/memory/
auto_online_blocks block_size_bytes memory1 memory2 memory2048 memory2049 memory2050 power probe uevent