Thread (5 messages) flat view 5 messages, 3 authors, 2013-01-07

Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

From: Konrad Rzeszutek Wilk <hidden>
Date: 2013-01-04 19:12:16
Also in: kexec, lkml, xen-devel

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:
quoted
quoted
quoted
quoted
On 04.01.13 at 15:22, Daniel Kiper [off-list ref] wrote:
On Wed, Jan 02, 2013 at 11:26:43AM +0000, Andrew Cooper wrote:
quoted
/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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help