search for: kexec_file_load

...make sure it didn't get > dropped. I see there were some reports about people having trouble > using this, pls keep working on this meanwhile. Hi Michael, I think this is ready to go as a first version. There are a couple of future work items related to kexec/kdump: - Teach kexec-tools/kexec_file_load() to not place the kexec kernel/initrd onto virtio-mem added memory. - Teach kexec-tools/kdump to consider a bigger number of memory resources for dumping. In general, as virtio-mem adds a lot of memory resources, we might want to tweak performance in that area as well. Future stuff. So I sug...

...make sure it didn't get > dropped. I see there were some reports about people having trouble > using this, pls keep working on this meanwhile. Hi Michael, I think this is ready to go as a first version. There are a couple of future work items related to kexec/kdump: - Teach kexec-tools/kexec_file_load() to not place the kexec kernel/initrd onto virtio-mem added memory. - Teach kexec-tools/kdump to consider a bigger number of memory resources for dumping. In general, as virtio-mem adds a lot of memory resources, we might want to tweak performance in that area as well. Future stuff. So I sug...

...rnel need not preemptively block it. So, I think I have to clarify something here. We do have two ways to kexec 1. kexec_load(): User space (kexec-tools) crafts the memmap (e.g., using /sys/firmware/memmap on x86-64) and selects memory where to place the kexec images (e.g., using /proc/iomem) 2. kexec_file_load(): The kernel reuses the (basically) raw firmware memmap and selects memory where to place kexec images. We are talking about changing 1, to behave like 2 in regards to dax/kmem. 2. does currently not add any hotplugged memory to the fixed-up e820, and it should be fixed regarding hotplugged DIMMs...

...rnel need not preemptively block it. So, I think I have to clarify something here. We do have two ways to kexec 1. kexec_load(): User space (kexec-tools) crafts the memmap (e.g., using /sys/firmware/memmap on x86-64) and selects memory where to place the kexec images (e.g., using /proc/iomem) 2. kexec_file_load(): The kernel reuses the (basically) raw firmware memmap and selects memory where to place kexec images. We are talking about changing 1, to behave like 2 in regards to dax/kmem. 2. does currently not add any hotplugged memory to the fixed-up e820, and it should be fixed regarding hotplugged DIMMs...

...-managed memory introduced in commit 75ac4c58bc0d ("mm/memory_hotplug: introduce add_memory_driver_managed()"). This will result in no entries in /sys/firmware/memmap ("raw firmware- provided memory map"), the memory resource will be flagged IORESOURCE_MEM_DRIVER_MANAGED (esp., kexec_file_load() will not place kexec images on this memory), and it is exposed as "System RAM (virtio_mem)" in /proc/iomem, so esp. kexec-tools can properly handle it. Example /proc/iomem before this change: [...] 140000000-333ffffff : virtio0 140000000-147ffffff : System RAM 334000000-533ff...

...-managed memory introduced in commit 75ac4c58bc0d ("mm/memory_hotplug: introduce add_memory_driver_managed()"). This will result in no entries in /sys/firmware/memmap ("raw firmware- provided memory map"), the memory resource will be flagged IORESOURCE_MEM_DRIVER_MANAGED (esp., kexec_file_load() will not place kexec images on this memory), and it is exposed as "System RAM (virtio_mem)" in /proc/iomem, so esp. kexec-tools can properly handle it. Example /proc/iomem before this change: [...] 140000000-333ffffff : virtio0 140000000-147ffffff : System RAM 334000000-533ff...

On 01.05.20 20:43, Dan Williams wrote: > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 20:03, Dan Williams wrote: >>> On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 19:45, David Hildenbrand wrote: >>>>> On 01.05.20

On 01.05.20 20:43, Dan Williams wrote: > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 20:03, Dan Williams wrote: >>> On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 19:45, David Hildenbrand wrote: >>>>> On 01.05.20

...opped. I see there were some reports about people having trouble > > using this, pls keep working on this meanwhile. > > Hi Michael, > > I think this is ready to go as a first version. There are a couple of > future work items related to kexec/kdump: > - Teach kexec-tools/kexec_file_load() to not place the kexec > kernel/initrd onto virtio-mem added memory. > - Teach kexec-tools/kdump to consider a bigger number of memory > resources for dumping. > > In general, as virtio-mem adds a lot of memory resources, we might want > to tweak performance in that area as...

...> > So, I think I have to clarify something here. We do have two ways to kexec > > 1. kexec_load(): User space (kexec-tools) crafts the memmap (e.g., using > /sys/firmware/memmap on x86-64) and selects memory where to place the > kexec images (e.g., using /proc/iomem) > > 2. kexec_file_load(): The kernel reuses the (basically) raw firmware > memmap and selects memory where to place kexec images. > > We are talking about changing 1, to behave like 2 in regards to > dax/kmem. 2. does currently not add any hotplugged memory to the > fixed-up e820, and it should be fixed re...

...o basically ignore any System RAM that's not on top level when searching for areas to place kexec images - but also for determining crash areas to dump via kdump. This behavior is not changed by this patch. kexec-tools probably has to be fixed to also include this memory in system dumps. Note: kexec_file_load() does the right thing already within the kernel. Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Pankaj Gupta <pankaj.gupta.linux at gmail.com> Cc: Wei Yang <richard.weiyang at gmail.com> Cc: Baoquan He <bhe at redhat.com> C...

...; in commit 75ac4c58bc0d ("mm/memory_hotplug: introduce > add_memory_driver_managed()"). > > This will result in no entries in /sys/firmware/memmap ("raw firmware- > provided memory map"), the memory resource will be flagged > IORESOURCE_MEM_DRIVER_MANAGED (esp., kexec_file_load() will not place > kexec images on this memory), and it is exposed as "System RAM > (virtio_mem)" in /proc/iomem, so esp. kexec-tools can properly handle it. > > Example /proc/iomem before this change: > [...] > 140000000-333ffffff : virtio0 > 140000000-147ff...

This is the follow up of [1]: [PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools I realized that this is not only helpful for virtio-mem, but also for dax/kmem - it's a fix for that use case (see patch #3) of persistent memory. Also, while testing, I discovered that kexec-tools will *not* add dax/kmem memory (anything not directly under the root when parsing

...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. Wh...