similar to: [PATCH v2 00/11] xen: Initial kexec/kdump implementation

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. 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. However, this solution requires some changes in baremetal x86 code. First of

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. 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. However, this solution requires some changes in baremetal x86 code. First of

Hi, This set of patches contains initial kexec/kdump implementation for Xen v3. 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. However, this solution requires some changes in baremetal x86 code. First of

vmcoreinfo file could exists under /sys/kernel (valid on baremetal only) and/or under /sys/hypervisor (valid when Xen dom0 is running). Read only one of them. It means that only one PT_NOTE will be always created. Remove extra code for second PT_NOTE creation. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> --- kexec/crashdump-elf.c | 33 +++++++-------------------------- 1 files

> Daniel Kiper <daniel.kiper at oracle.com> writes: > > > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default > > Linux infrastructure and require some support from firmware and/or hypervisor. > > To cope with that problem kexec firmware infrastructure was introduced. > > It allows a developer to use all kexec/kdump features of given firmware

> Daniel Kiper <daniel.kiper at oracle.com> writes: > > > Some kexec/kdump implementations (e.g. Xen PVOPS) could not use default > > Linux infrastructure and require some support from firmware and/or hypervisor. > > To cope with that problem kexec firmware infrastructure was introduced. > > It allows a developer to use all kexec/kdump features of given firmware

Hi all, Here I am sending as attachments patches enabling kexec/kdump support in Xen PV domU. Only x84_64 architecture is supported. There is no support for i386 but some code could be easily reused. Here is a description of patches: - kexec-tools-2.0.3_20120522.patch: patch for kexec-tools which cleanly applies to version 2.0.3, - kexec-kernel-only_20120522.patch: main kexec/kdump kernel

Hi all, Here I am sending as attachments patches enabling kexec/kdump support in Xen PV domU. Only x84_64 architecture is supported. There is no support for i386 but some code could be easily reused. Here is a description of patches: - kexec-tools-2.0.3_20120522.patch: patch for kexec-tools which cleanly applies to version 2.0.3, - kexec-kernel-only_20120522.patch: main kexec/kdump kernel

Hi all, Here I am sending as attachments patches enabling kexec/kdump support in Xen PV domU. Only x84_64 architecture is supported. There is no support for i386 but some code could be easily reused. Here is a description of patches: - kexec-tools-2.0.3_20120522.patch: patch for kexec-tools which cleanly applies to version 2.0.3, - kexec-kernel-only_20120522.patch: main kexec/kdump kernel

> On 12/26/2012 06:18 PM, Daniel Kiper wrote: > > Add i386 kexec/kdump implementation. > > > > v2 - suggestions/fixes: > > - allocate transition page table pages below 4 GiB > > (suggested by Jan Beulich). > > Why? Sadly all addresses are passed via unsigned long variable to kexec hypercall. Daniel

> On 12/26/2012 06:18 PM, Daniel Kiper wrote: > > Add i386 kexec/kdump implementation. > > > > v2 - suggestions/fixes: > > - allocate transition page table pages below 4 GiB > > (suggested by Jan Beulich). > > Why? Sadly all addresses are passed via unsigned long variable to kexec hypercall. Daniel

All, I''m posting to the Xen-devel list and the OSDL fastboot list. There are a number of Xen folks who''ll want to look at the code. For the fastboot folks, this is mostly intended as an announcement of the port. Please limit your replies to the list(s) that they applies to, thanks :-) A number of people have expressed interest in kexec support for Xen guests. In

On 29.03.20 14:42, Michael S. Tsirkin wrote: > On Wed, Mar 11, 2020 at 06:14:12PM +0100, David Hildenbrand wrote: >> This series is based on latest linux-next. The patches are located at: >> https://github.com/davidhildenbrand/linux.git virtio-mem-v2 >> >> I now have acks for all !virtio-mem changes. I'll be happy to get review >> feedback, testing reports,

On 29.03.20 14:42, Michael S. Tsirkin wrote: > On Wed, Mar 11, 2020 at 06:14:12PM +0100, David Hildenbrand wrote: >> This series is based on latest linux-next. The patches are located at: >> https://github.com/davidhildenbrand/linux.git virtio-mem-v2 >> >> I now have acks for all !virtio-mem changes. I'll be happy to get review >> feedback, testing reports,

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

Howdy, Running a round of updates from 6.3 to 6.4 and I'm seeing the following on all the servers. Want to make sure I'm not going to end up with a kernel panic if I reboot into the new kernel or have any other issues. Apr 22 11:10:21 www kdump: kexec: unloaded kdump kernel Apr 22 11:10:21 www kdump: stopped Apr 22 11:10:21 www kdump: mkdumprd: failed to make kdump initrd Apr 22

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

Hi I have both host and KVM/QEMU guest VM running linux. Questions: What are the constituents of the virsh dump? - What all areas does it dumps? - Is it same as taking guest VM's core dump via kexec/kdump? - Does it include QEMU's info to debug qemu-level issues? Thanks much in advance. >harish -------------- next part -------------- An HTML attachment was scrubbed... URL: