From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com ([205.139.110.61]:60981 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726524AbgD2QIf (ORCPT ); Wed, 29 Apr 2020 12:08:35 -0400 From: David Hildenbrand Subject: [PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools Date: Wed, 29 Apr 2020 18:08:00 +0200 Message-Id: <20200429160803.109056-1-david@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: linux-s390-owner@vger.kernel.org List-ID: To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, virtio-dev@lists.oasis-open.org, virtualization@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org, linux-acpi@vger.kernel.org, linux-nvdimm@lists.01.org, linux-hyperv@vger.kernel.org, linux-s390@vger.kernel.org, xen-devel@lists.xenproject.org, Michal Hocko , Andrew Morton , "Michael S . Tsirkin" , David Hildenbrand , Baoquan He , Benjamin Herrenschmidt , Boris Ostrovsky , Christian Borntraeger , Dan Williams , Dave Jiang , Eric Biederman , Greg Kroah-Hartman , Haiyang Zhang , Heiko Carstens , Jason Wang , Juergen Gross , "K. Y. Srinivasan" , Len Brown , Leonardo Bras , Michael Ellerman , Michal Hocko , Nathan Lynch , Oscar Salvador , Pankaj Gupta , Paul Mackerras , Pingfan Liu , "Rafael J. Wysocki" , Stefano Stabellini , Stephen Hemminger , Thomas Gleixner , Vasily Gorbik , Vishal Verma , Wei Liu , Wei Yang This series is based on [1]: [PATCH v2 00/10] virtio-mem: paravirtualized memory That will hopefull get picked up soon, rebased to -next. The following patches were reverted from -next [2]: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use As discussed in that thread, they should be reverted from -next already. In theory, if people agree, we could take the first two patches via the -mm tree now and the last (virtio-mem) patch via MST's tree once picking = up virtio-mem. No strong feelings. Memory added by virtio-mem is special and might contain logical holes, especially after memory unplug, but also when adding memory in sub-section size. While memory in these holes can usually be read, that memory should not be touched. virtio-mem managed device memory is never exposed via any firmware memmap (esp., e820). The device driver will request to plug memory from the hypervisor and add it to Linux. On a cold start, all memory is unplugged, and the guest driver will first request to plug memory from the hypervisor, to then add it to Linux. Afte= r a reboot, all memory will get unplugged (except in rare, special cases). = In case the device driver comes up and detects that some memory is still plugged after a reboot, it will manually request to unplug all memory fro= m the hypervisor first - to then request to plug memory from the hypervisor and add to Linux. This is essentially a defragmentation step, where all logical holes are removed. As the device driver is responsible for detecting, adding and managing th= at memory, also kexec should treat it like that. It is special. We need a wa= y to teach kexec-tools to not add that memory to the fixed-up firmware memmap, to not place kexec images onto this memory, but still allow kdump to dump it. Add a flag to tell memory hotplug code to not create /sys/firmware/memmap entries and to indicate it via "System RAM (driver managed)" in /proc/iomem. Before this series, kexec_file_load() already did the right thing (for virtio-mem) by not adding that memory to the fixed-up firmware memmap and letting the device driver handle it. With this series, also kexec_load() = - which relies on user space to provide a fixed up firmware memmap - does the right thing with virtio-mem memory. When the virtio-mem device driver(s) come up, they will request to unplug all memory from the hypervisor first (esp. defragment), to then request t= o plug consecutive memory ranges from the hypervisor, and add them to Linux - just like on a reboot where we still have memory plugged. [1] https://lore.kernel.org/r/20200311171422.10484-1-david@redhat.com/ [2] https://lore.kernel.org/r/20200326180730.4754-1-james.morse@arm.com David Hildenbrand (3): mm/memory_hotplug: Prepare passing flags to add_memory() and friends mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED virtio-mem: Add memory with MHP_DRIVER_MANAGED arch/powerpc/platforms/powernv/memtrace.c | 2 +- .../platforms/pseries/hotplug-memory.c | 2 +- drivers/acpi/acpi_memhotplug.c | 2 +- drivers/base/memory.c | 2 +- drivers/dax/kmem.c | 2 +- drivers/hv/hv_balloon.c | 2 +- drivers/s390/char/sclp_cmd.c | 2 +- drivers/virtio/virtio_mem.c | 3 +- drivers/xen/balloon.c | 2 +- include/linux/memory_hotplug.h | 15 +++++++-- mm/memory_hotplug.c | 31 +++++++++++++------ 11 files changed, 44 insertions(+), 21 deletions(-) --=20 2.25.3