On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote: > On Fri, Jan 04, 2013 at 02:41:17PM +0000, Jan Beulich wrote: > > >>> On 04.01.13 at 15:22, Daniel Kiper <daniel.ki...@oracle.com> wrote: > > > On Wed, Jan 02, 2013 at 11:26:43AM +0000, Andrew Cooper wrote: > > >> /sbin/kexec can load the "Xen" crash kernel itself by issuing > > >> hypercalls using /dev/xen/privcmd. This would remove the need for > > >> the dom0 kernel to distinguish between loading a crash kernel for > > >> itself and loading a kernel for Xen. > > >> > > >> Or is this just a silly idea complicating the matter? > > > > > > This is impossible with current Xen kexec/kdump interface. > > > > Why? > > Because current KEXEC_CMD_kexec_load does not load kernel > image and other things into Xen memory. It means that it > should live somewhere in dom0 Linux kernel memory.
We could have a very simple hypercall which would have: struct fancy_new_hypercall { xen_pfn_t payload; // IN ssize_t len; // IN #define DATA (1<<1) #define DATA_EOF (1<<2) #define DATA_KERNEL (1<<3) #define DATA_RAMDISK (1<<4) unsigned int flags; // IN unsigned int status; // OUT }; which would in a loop just iterate over the payloads and let the hypervisor stick it in the crashkernel space. This is all hand-waving of course. There probably would be a need to figure out how much space you have in the reserved Xen's 'crashkernel' memory region too. > > Daniel _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization