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
> "-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
We 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
> 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