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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 27/12/2012 07:53, Eric W. Biederman wrote:
> The syscall ABI still has the wrong semantics.
>
> Aka totally unmaintainable and umergeable.
>
> The concept of domU support is also strange.  What does domU support even 
> mean, when the dom0 support is loading a kernel to pick up Xen when Xen falls 
> over.

There are two requirements pulling at this patch series, but I agree
that we need to clarify them.

When dom0 loads a crash kernel, it is loading one for Xen to use.  As a
dom0 crash causes a Xen crash, having dom0 set up a kdump kernel for
itself is completely useless.  This ability is present in "classic Xen
dom0" kernels, but the feature is currently missing in PVOPS.

Many cloud customers and service providers want the ability for a VM
administrator to be able to load a kdump/kexec kernel within a
domain[1].  This allows the VM administrator to take more proactive
steps to isolate the cause of a crash, the state of which is most likely
discarded while tearing down the domain.  The result being that as far
as Xen is concerned, the domain is still alive, while the kdump
kernel/environment can work its usual magic.  I am not aware of any
feature like this existing in the past.

~Andrew

[1] http://lists.xen.org/archives/html/xen-devel/2012-11/msg01274.html

>
> I expect a lot of decisions about what code can be shared and what code can't 
> is going to be driven by the simple question what does the syscall mean.
>
> Sharing machine_kexec.c and relocate_kernel.S does not make much sense to me 
> when what you are doing is effectively passing your arguments through to the 
> Xen version of kexec.
>
> Either Xen has it's own version of those routines or I expect the Xen version 
> of kexec is buggy.   I can't imagine what sharing that code would mean.  By 
> the same token I can't any need to duplicate the code either.
>
> Furthermore since this is just passing data from one version of the syscall 
> to another I expect you can share the majority of the code across all 
> architectures that implement Xen.  The only part I can see being arch 
> specific is the Xen syscall stub.
>
> With respect to the proposed semantics of silently giving the kexec system 
> call different meaning when running under Xen,
> /sbin/kexec has to act somewhat differently when loading code into the Xen 
> hypervisor so there is no point not making that explicit in the ABI.
>
> Eric
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel