On Thu, Apr 19, 2012 at 04:08:38PM +0200, Vasilis Liaskovitis wrote:
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
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
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
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
can add ,populated=true to -memslot to make slot populated from the
start. We will need it for migration anyway.
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.
OK, I hope final version will allow for
memory < 4G to be hot-pluggable.
- 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
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