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:This would have to be XEN_GUEST_HANDLE(something) since userspace cannotBecause current KEXEC_CMD_kexec_load does not load kernelWe could have a very simple hypercall which would have:
image and other things into Xen memory. It means that it
should live somewhere in dom0 Linux kernel memory.
struct fancy_new_hypercall {
xen_pfn_t payload; // IN
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; // INThis is probably a mad idea but it's Monday morning and I'm sleep
#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.
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.