similar to: kdump on Xen 4.1, ubuntu 12.04 and kernel 3.2.0

Add guide to using the kexec and kdump facility in xen. Signed-off-by: Simon Horman <horms@verge.net.au> --- I the work on this document using an ia64 machine and qemu emulating x86_32. I am yet to verify it on x86_32 hardware or x86_64. Index: xen-unstable.hg/docs/misc/kexec_and_kdump.txt =================================================================== --- /dev/null 1970-01-01

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

Hi, This set of patches contains initial kexec/kdump implementation for Xen v2 (previous version were posted to few people by mistake; sorry for that). Currently only dom0 is supported, however, almost all infrustructure required for domU support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code.

On 30.04.20 10:11, Dan Williams wrote: > On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 29.04.20 18:08, David Hildenbrand wrote: >>> Some paravirtualized devices that add memory via add_memory() and >>> friends (esp. virtio-mem) don't want to create entries in >>> /sys/firmware/memmap/ - primarily to

On 29.04.20 18:08, David Hildenbrand wrote: > Some paravirtualized devices that add memory via add_memory() and > friends (esp. virtio-mem) don't want to create entries in > /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the firmware (e.g., e820), but > only

On 29.04.20 18:08, David Hildenbrand wrote: > Some paravirtualized devices that add memory via add_memory() and > friends (esp. virtio-mem) don't want to create entries in > /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the firmware (e.g., e820), but > only

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

On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: > > On 01.05.20 18:56, Dan Williams wrote: > > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: > >> > >> On 01.05.20 00:24, Andrew Morton wrote: > >>> On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com>

On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: > > On 01.05.20 18:56, Dan Williams wrote: > > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: > >> > >> On 01.05.20 00:24, Andrew Morton wrote: > >>> On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com>

On 01.05.20 19:45, David Hildenbrand wrote: > On 01.05.20 19:39, Dan Williams wrote: >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: >>> >>> On 01.05.20 18:56, Dan Williams wrote: >>>> On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: >>>>> >>>>> On

On 01.05.20 19:45, David Hildenbrand wrote: > On 01.05.20 19:39, Dan Williams wrote: >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: >>> >>> On 01.05.20 18:56, Dan Williams wrote: >>>> On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: >>>>> >>>>> On

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 19:39, Dan Williams wrote: >>>> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: >>>>> >>>>> On 01.05.20

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 19:39, Dan Williams wrote: >>>> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: >>>>> >>>>> On 01.05.20

On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: > > On 01.05.20 00:24, Andrew Morton wrote: > > On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com> wrote: > > > >>> > >>> Why does the firmware map support hotplug entries? > >> > >> I assume: > >> > >> The

On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: > > On 01.05.20 00:24, Andrew Morton wrote: > > On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com> wrote: > > > >>> > >>> Why does the firmware map support hotplug entries? > >> > >> I assume: > >> > >> The

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

On 01.05.20 22:12, Dan Williams wrote: > On Fri, May 1, 2020 at 12:18 PM David Hildenbrand <david at redhat.com> wrote: >> >> 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

On 01.05.20 22:12, Dan Williams wrote: > On Fri, May 1, 2020 at 12:18 PM David Hildenbrand <david at redhat.com> wrote: >> >> 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