similar to: [PATCH v3 01/11] kexec: introduce kexec firmware support

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

> 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

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.

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

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

xc_interface_close() crashes if it gets NULL as an argument. However, it just calls xc_interface_close_common() which is called by many others functions. It means that they are also vulnerable. So fix above mentioned issue by adding NULL check in xc_interface_close_common(). This way we fix similar issue in other functions which calls xc_interface_close_common() too. Signed-off-by: Daniel Kiper

Hi, In the case of linux, crash_kexec() is occured by "sysrq c". In the case of DomainU on xen, Help is occured by "sysrq c" now. So The way of dumping DomainU''s memory manualy is nothing. I fix this issue by the following way. 1. Panic is occured by "sysrq c" on both Domain0 and DomainU. 2. On DomainU, coredump is generated in /var/xen/dump (on Domain0).

Remove the kdump generated kernel crash data. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- sysprep/Makefile.am | 1 + sysprep/sysprep_operation_crash_data.ml | 47 +++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+) create mode 100644 sysprep/sysprep_operation_crash_data.ml diff --git a/sysprep/Makefile.am b/sysprep/Makefile.am index

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

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

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