This is a prototype for ACPI memory hotplug on x86_64 target. Based on some earlier work and comments from Gleb.
Memslot devices are modeled with a new qemu command line
"-memslot id=name,start=start_addr,size=sz,node=pxm"
user is responsible for defining memslots with meaningful start/size values, e.g. not defining a memory slot over a PCI-hole. Alternatively, the start size could also be handled/assigned automatically from the specific emulated hardware (for hw/pc.c PCI hole is currently [below_4g_mem_size, 4G), so hotplugged memory should start from max(4G, above_4g_mem_size).
Node is defining numa proximity for this memslot. When not defined it defaults to zero.
e.g. "-memslot id=hot1,start=4294967296,size=536870912,node=0" will define a 512M memory slot starting at physical address 4G, belonging to numa node 0.
Memory slots are added or removed with a new hmp command "memslot": Hot-add syntax: "memslot id add" Hot-remove syntax: "memslot id delete"
- All memslots are initially unpopulated. Memslots are currently modeling only hotplug-able memory slots i.e. initial system memory is not modeled with memslots. The concept could be generalized to include all memory though, or it could more closely follow kvm-memory slots.
- Memslots are abstracted as qdevices attached to the main system bus. However, memory hotplugging has its own side channel ignoring main_system_bus's hotplug incapability. A cleaner integration would be needed. What's the preferred way of modeling memory devices in qom? Would it be better to attach memory devices as children-links of an acpi-capable device (in the pc case acpi_piix4) instead of the system bus?
- Refcounting memory slots has been discussed (but is not included in this series yet). Depopulating a memory region happens on a guestOS _EJ callback, which means the guestOS will not be using the region anymore. However, guest addresses from the depopulated region need to also be unmapped from the qemu address space using cpu_physical_memory_unmap(). Does memory_region_del_subregion() or some other memory API call guarantee that a memoryregion has been unmapped from qemu's address space?
- What is the expected behaviour of hotplugged memory after a reboot? Is it supposed to be persistent after reboots? The last 2 patches in the series try to make hotplugged memslots persistent after reboot by creating and consulting e820 map entries. A better solution is needed for hot-remove after a reboot, because e820 entries can be merged.
series is based on uq/master for qemu-kvm, and master for seabios. Can be found also at:
Vasilis Liaskovitis (9): Seabios: Add SSDT memory device support Seabios, acpi: Implement acpi-dsdt functions for memory hotplug. Seabios, acpi: generate hotplug memory devices. Implement memslot device abstraction acpi_piix4: Implement memory device hotplug registers and handlers. pc: pass paravirt info for hotplug memory slots to BIOS Implement memslot command-line option and memslot hmp monitor command pc: adjust e820 map on hot-add and hot-remove Seabios, acpi: enable memory devices if e820 entry is present
Makefile.objs | 2 +- hmp-commands.hx | 15 ++++ hw/acpi_piix4.c | 103 +++++++++++++++++++++++++++- hw/memslot.c | 201 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ hw/memslot.h | 44 ++++++++++++ hw/pc.c | 87 ++++++++++++++++++++++-- hw/pc.h | 1 + monitor.c | 8 ++ monitor.h | 1 + qemu-config.c | 25 +++++++ qemu-options.hx | 8 ++ sysemu.h | 1 + vl.c | 44 ++++++++++++- 13 files changed, 528 insertions(+), 12 deletions(-) create mode 100644 hw/memslot.c create mode 100644 hw/memslot.h
create mode 100644 src/ssdt-mem.dsl src/acpi-dsdt.dsl | 68 ++++++++++++++++++++++- src/acpi.c | 155 +++++++++++++++++++++++++++++++++++++++++++++++++++-- src/memmap.c | 15 +++++ src/ssdt-mem.dsl | 66 ++++++++++++++++++++++ 4 files changed, 298 insertions(+), 6 deletions(-) create mode 100644 src/ssdt-mem.dsl