Hi,
Currently, I am working on kexec/kdump for Xen with emphasis on dom0
implementation issues. After reviewing relevant Xen Linux Kernel
Ver. 2.6.18 code I realized (as I expected) that original kexec/kdump
in mainline kernel should be extensively amended. Further, after some
discussion with Konrad Rzeszutek Wilk and Ian Campbell it was clear
for me that it could be done in a few diffrent ways. Due to this facts
I decided to establish general implementation details with LKML and
Xen-devel community to avoid extensive code rewrite in case my own
proposal would not be accepted.
Now I think about four solutions. I will present them in order of my
preference. However, if you have another soultions to that problem
please drop me a line.
1) Currently existing kexec/kdump implementation should be amended
by adding Xen specific code mainly in arch/i386. It should look
like:
void machine_kexec(struct kimage *image)
{
#ifdef CONFIG_XEN
if (xen_initial_domain()) {
...
Xen specific code
...
}
#endif
...
generic kexec/kdump code
...
}
2) Information about architecture depended kexec/kdump code should
be stored in struct machine_kexec_ops. It should contain
references to machine specific functions:
struct machine_kexec_ops {
void (*machine_kexec)(struct kimage *image);
...
}
This structure should be initialized properly at system startup.
3) kexec-tools should be able to detect current machine type. If it
detects Xen hypervisor it should call relevant (Xen specific)
ioctl() to perform kexec (Xen specific) instead of standard
kexec syscall.
4) kexec-tools should be able to detect current machine type. If it
detects Xen hypervisor it should call newly established Xen specific
kexec syscall (lets call it sys_kexec_load_xen()) to perform kexec
(Xen specific) instead of standard kexec syscall.
I am looking forward for your comments, suggestions, etc.
Daniel
On Mon, 2011-06-06 at 17:04 +0100, Daniel Kiper wrote:
> Hi,
>
> Currently, I am working on kexec/kdump for Xen with emphasis on dom0
> implementation issues. After reviewing relevant Xen Linux Kernel
> Ver. 2.6.18 code I realized (as I expected) that original kexec/kdump
> in mainline kernel should be extensively amended. Further, after some
> discussion with Konrad Rzeszutek Wilk and Ian Campbell it was clear
> for me that it could be done in a few diffrent ways. Due to this facts
> I decided to establish general implementation details with LKML and
> Xen-devel community to avoid extensive code rewrite in case my own
> proposal would not be accepted.
>
> Now I think about four solutions. I will present them in order of my
> preference. However, if you have another soultions to that problem
> please drop me a line.
>
> 1) Currently existing kexec/kdump implementation should be amended
> by adding Xen specific code mainly in arch/i386. It should look
> like:
>
> void machine_kexec(struct kimage *image)
> {
> #ifdef CONFIG_XEN
> if (xen_initial_domain()) {
> ...
> Xen specific code
> ...
> }
> #endif
>
> ...
> generic kexec/kdump code
> ...
> }
This is about the ugliest way to do things and should be avoided.
Perhaps the actual kexec op (as opposed to any setup or control ops)
would make a reasonable addition to the existing machine_ops?
A lot of the other #ifdef ...XEN in the out of tree 2.6.18 code
(actually I'm looking at a 2.6.32 Novell fwd port) seem like they would
go away through the use of existing pvops (e.g. those for manipulating
page tables since the Xen implementations of those already incorporate
the necessary p2m translation).
> 2) Information about architecture depended kexec/kdump code should
> be stored in struct machine_kexec_ops. It should contain
> references to machine specific functions:
>
> struct machine_kexec_ops {
> void (*machine_kexec)(struct kimage *image);
> ...
> }
>
> This structure should be initialized properly at system startup.
I think this approach would generally be much preferable to 1, 3, and 4.
We should be careful to ensure that any such hooks are actually needed
though and that they don't belong anywhere else -- I expect mostly
things will be covered by existing *_ops.
>
> 3) kexec-tools should be able to detect current machine type. If it
> detects Xen hypervisor it should call relevant (Xen specific)
> ioctl() to perform kexec (Xen specific) instead of standard
> kexec syscall.
>
> 4) kexec-tools should be able to detect current machine type. If it
> detects Xen hypervisor it should call newly established Xen specific
> kexec syscall (lets call it sys_kexec_load_xen()) to perform kexec
> (Xen specific) instead of standard kexec syscall.
>
> I am looking forward for your comments, suggestions, etc.
>
> Daniel
On Tue, Jun 07, 2011 at 11:29:26AM +0100, Ian Campbell wrote:
> On Mon, 2011-06-06 at 17:04 +0100, Daniel Kiper wrote:
> > Hi,
> >
> > Currently, I am working on kexec/kdump for Xen with emphasis on dom0
> > implementation issues. After reviewing relevant Xen Linux Kernel
> > Ver. 2.6.18 code I realized (as I expected) that original kexec/kdump
> > in mainline kernel should be extensively amended. Further, after some
> > discussion with Konrad Rzeszutek Wilk and Ian Campbell it was clear
> > for me that it could be done in a few diffrent ways. Due to this facts
> > I decided to establish general implementation details with LKML and
> > Xen-devel community to avoid extensive code rewrite in case my own
> > proposal would not be accepted.
> >
> > Now I think about four solutions. I will present them in order of my
> > preference. However, if you have another soultions to that problem
> > please drop me a line.
> >
> > 1) Currently existing kexec/kdump implementation should be amended
> > by adding Xen specific code mainly in arch/i386. It should look
> > like:
> >
> > void machine_kexec(struct kimage *image)
> > {
> > #ifdef CONFIG_XEN
> > if (xen_initial_domain()) {
> > ...
> > Xen specific code
> > ...
> > }
> > #endif
> >
> > ...
> > generic kexec/kdump code
> > ...
> > }
>
> This is about the ugliest way to do things and should be avoided.
I think that in this case it is to some extent. I decided put
this solution before struct machine_kexec_ops solution because
this (let say conditional solution) touches only x86 code (and
if it be required IA-64). struct machine_kexec_ops proposal
require changes for 8 archs. I am not sure it could be accepted
by kexec/kdump and relevant archs maintainers quickly. However,
I think that struct machine_kexec_ops is better as longterm
solution.
Daniel
On Wed, Jun 08, 2011 at 06:04:45PM +0200, Daniel Kiper wrote:
> On Tue, Jun 07, 2011 at 11:29:26AM +0100, Ian Campbell wrote:
> > On Mon, 2011-06-06 at 17:04 +0100, Daniel Kiper wrote:
> > > Hi,
> > >
> > > Currently, I am working on kexec/kdump for Xen with emphasis on dom0
> > > implementation issues. After reviewing relevant Xen Linux Kernel
> > > Ver. 2.6.18 code I realized (as I expected) that original kexec/kdump
> > > in mainline kernel should be extensively amended. Further, after some
> > > discussion with Konrad Rzeszutek Wilk and Ian Campbell it was clear
> > > for me that it could be done in a few diffrent ways. Due to this facts
> > > I decided to establish general implementation details with LKML and
> > > Xen-devel community to avoid extensive code rewrite in case my own
> > > proposal would not be accepted.
> > >
> > > Now I think about four solutions. I will present them in order of my
> > > preference. However, if you have another soultions to that problem
> > > please drop me a line.
> > >
> > > 1) Currently existing kexec/kdump implementation should be amended
> > > by adding Xen specific code mainly in arch/i386. It should look
> > > like:
> > >
> > > void machine_kexec(struct kimage *image)
> > > {
> > > #ifdef CONFIG_XEN
> > > if (xen_initial_domain()) {
> > > ...
> > > Xen specific code
> > > ...
> > > }
> > > #endif
> > >
> > > ...
> > > generic kexec/kdump code
> > > ...
> > > }
> >
> > This is about the ugliest way to do things and should be avoided.
>
> I think that in this case it is to some extent. I decided put
> this solution before struct machine_kexec_ops solution because
> this (let say conditional solution) touches only x86 code (and
> if it be required IA-64). struct machine_kexec_ops proposal
> require changes for 8 archs. I am not sure it could be accepted
> by kexec/kdump and relevant archs maintainers quickly. However,
Slowly is in general how LKML works with patches. Once you have
an idea of how you want the callback/structs be set lets
email the maintainer of the kexec to get his feedback. If he is OK
then I don't think the different arch maintainers will care much
(as long as it has been tested - and that can be done with QEMU).
> I think that struct machine_kexec_ops is better as longterm
> solution.
Sounds like that is the winner then.