Messages in this thread | | | Date | Fri, 4 Jan 2013 14:11:46 -0500 | From | Konrad Rzeszutek Wilk <> | Subject | Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation |
| |
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.kiper@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
| |