Re: [Xen-devel] kexec trouble

["Magnus Damm" <magnus.damm@xxxxxxxxx>]

On 12/6/06, Gerd Hoffmann <kraxel@xxxxxxx> wrote:
>   Hi,
>
> > We chit-chatted a bit, but I don't remember us talking about any
> > implementation details.
>
> Discussed briefly possible code sharing, that there likely isn't much to
> share because we have two very different approachs to take, and that we
> are probably best off just having two machine_kexec() versions for
> dom0/domU.  No details yet how to actually implement that, but at least
> the need for some kind of runtime switching should have been clear.
We needed to work together to implement runtime switching anyhow, and
that's what is happening now. But maybe I should have considered the
runtime switching earlier...

> > I've heard complaints and doubts about using sparse together with
> > patches, but when I ask for a better alternative it's always awfully
> > silent. We could have copied the files into sparse and applied our
> > patches, but duplicating files seemed a step in the wrong direction.
>
> For backports and code planned for quick mainline merge maintaining as
> patches is fine, makes it easier to move forward once stuff is merged
> and/or the xen linux tree is updated to a newer upstream kernel.
Ack.

> For code which likely lives longer in the xen tree (especially
> kexec-generic.patch which has almost no chance to be accepted mainline
> as-is) it is a pain to deal with as patch.
Yeah, I can agree with that. Feel free to add the files to sparse and
throw out the patch. The dependency on patches and other stuff may
make it difficult though.

> I'd love to see kernel/kexec.c not being touched at all, but I think
> that is impossible for dom0 kexec (due to range checks which must happen
> in machine not guest address space for example).
We hoped to not touch the generic code at all too, but we had to
because of machine addresses

> >> So we can make machine_kexec() + friends function pointers, rename the
> >> native functions and initialize the function pointers to the native
> >> versions.  I think it should even be possible to make them function
> >> pointers for i386/x86_64 archs only.  Things keep working with
> >> CONFIG_XEN=n then, and with CONFIG_XEN=y the initialization function
> >> just switches the function pointers (depending on is_initial_domain()).
> >>  This also eliminates the first set of #ifdefs in kernel/kexec.c ;)
> >
> > Sounds exactly what I would have done! =)
>
> Great, so lets do that.
Excellent! Let me know how and where you want my help.

> > You seem to code with the goal of having something that will be
> > directly acceptable for mainilne, but my goal is to write as simple
> > code as possible which should be easy to adjust to whatever framework
> > that exists at the time of mainline merge.
>
> Given that the framework will be paravirt_ops function pointers fit
> nicely ;)
Function pointers sound like the right way to go! Happy hacking!

Thanks,

/ magnus

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel