From: Konrad Rzeszutek Wilk <hidden> Date: 2013-01-04 19:12:16
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.
From: Ian Campbell <hidden> Date: 2013-01-07 10:25:50
On Fri, 2013-01-04 at 19:11 +0000, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
quoted
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
This would have to be XEN_GUEST_HANDLE(something) since userspace cannot
figure out what pfns back its memory. In any case since the hypervisor
is going to want to copy the data into the crashkernel space a virtual
address is convenient to have.
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.
This is probably a mad idea but it's Monday morning and I'm sleep
deprived so I'll throw it out there...
What about adding DOMID_KEXEC (similar DOMID_IO etc)? This would allow
dom0 to map the kexec memory space with the usual privcmd mmap
hypercalls and build things in it directly.
OK, I suspect this might not be practical for a variety of reasons (lack
of a p2m for such domains so no way to find out the list of mfns, dom0
userspace simply doesn't have sufficient context to write sensible
things here, etc) but maybe someone has a better head on today...
Ian.
From: Daniel Kiper <hidden> Date: 2013-01-07 12:34:53
On Fri, Jan 04, 2013 at 02:11:46PM -0500, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
quoted
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.
I think that new kexec hypercall function should mimics kexec syscall.
It means that all arguments passed to hypercall should have same types
if it is possible or if it is not possible then conversion should be done
in very easy way. Additionally, I think that one call of new hypercall
load function should load all needed thinks in right place and
return relevant status. Last but not least, new functionality should
be available through /dev/xen/privcmd or directly from kernel without
bigger effort.
Daniel
From: Ian Campbell <hidden> Date: 2013-01-07 13:49:44
On Mon, 2013-01-07 at 12:34 +0000, Daniel Kiper wrote:
I think that new kexec hypercall function should mimics kexec syscall.
We want to have an interface can be used by non-Linux domains (both dom0
and domU) as well though, so please bear this in mind.
Historically we've not always been good at this when the hypercall
interface is strongly tied to a particular guest implementation (in some
sense this is the problem with the current kexec hypercall).
Also what makes for a good syscall interface does not necessarily make
for a good hypercall interface.
Ian.
From: Konrad Rzeszutek Wilk <hidden> Date: 2013-01-07 16:21:00
On Mon, Jan 07, 2013 at 01:34:04PM +0100, Daniel Kiper wrote:
On Fri, Jan 04, 2013 at 02:11:46PM -0500, Konrad Rzeszutek Wilk wrote:
quoted
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
quoted
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.
I think that new kexec hypercall function should mimics kexec syscall.
It means that all arguments passed to hypercall should have same types
if it is possible or if it is not possible then conversion should be done
in very easy way. Additionally, I think that one call of new hypercall
load function should load all needed thinks in right place and
return relevant status. Last but not least, new functionality should
We are not restricted to just _one_ hypercall. And this loading
thing could be similar to the micrcode hypercall - which just points
to a virtual address along with the length - and says 'load me'.
be available through /dev/xen/privcmd or directly from kernel without
bigger effort.
Perhaps we should have a email thread on xen-devel where we hash out
some ideas. Eric, would you be OK included on this - it would make
sense for this mechanism to be as future-proof as possible - and I am not
sure what your plans for kexec are in the future?