Re: [PATCH v2 01/11] kexec: introduce kexec_ops struct

On Fri, Nov 23, 2012 at 10:51:55AM +0000, Jan Beulich wrote:

quoted

quoted

quoted

On 23.11.12 at 11:37, Daniel Kiper [off-list ref] wrote:

On Fri, Nov 23, 2012 at 09:53:37AM +0000, Jan Beulich wrote:

quoted

quoted

quoted

quoted

On 23.11.12 at 02:56, Andrew Cooper [off-list ref] wrote:

On 23/11/2012 01:38, H. Peter Anvin wrote:

quoted

I still don't really get why it can't be isolated from dom0, which would

make more sense to me, even for a Xen crash.

quoted

The crash region (as specified by crashkernel= on the Xen command line)
is isolated from dom0.

dom0 (using the kexec utility etc) has the task of locating the Xen
crash notes (using the kexec hypercall interface), constructing a binary
blob containing kernel, initram and gubbins, and asking Xen to put this
blob in the crash region (again, using the kexec hypercall interface).

I do not see how this is very much different from the native case
currently (although please correct me if I am misinformed).  Linux has
extra work to do by populating /proc/iomem with the Xen crash regions
boot (so the kexec utility can reference their physical addresses when
constructing the blob), and should just act as a conduit between the
kexec system call and the kexec hypercall to load the blob.

But all of this _could_ be done completely independent of the
Dom0 kernel's kexec infrastructure (i.e. fully from user space,
invoking the necessary hypercalls through the privcmd driver).

No, this is impossible. kexec/kdump image lives in dom0 kernel memory
until execution. That is why privcmd driver itself is not a solution
in this case.

Even if so, there's no fundamental reason why that kernel image
can't be put into Xen controlled space instead.

Yep, but we must change Xen kexec interface and/or its behavior first.
If we take that option then we could also move almost all needed things
from dom0 kernel to Xen. This way we could simplify Linux Kernel
kexec/kdump infrastructure needed to run on Xen.

Daniel