Re: [Xen-devel] kexec trouble

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

Hi again Gerd,

[CC Simon]

On 12/6/06, Gerd Hoffmann <kraxel@xxxxxxx> wrote:
> >> I'm also in trouble now with guest kexec patches as they work with guest
> >> phys addrs not machine phys addrs.
> >
> > Sorry if that made your life difficult, but shouldn't it just be a
> > matter of using the native versions of the page macros for domU?
>
> No.  The same xen kernel can run as both dom0 and domU, thus that must
> be decided at runtime.
Well, for us there was no need to decide that at runtime. Our scope
was only dom0.

For you a runtime check makes sense, especially now when our code is
merged and you have a conflict. It does however sound like you are
pissed because the conflict, but I don't think you should blame that
on us. Simon and I reposted the patches at least 10 times over the
last half a year - so you had your time to come with feedback.

That aside, what about doing as little as possible now? Use
is_initial_xendomain() or something like that to switch between the
different dom0 and domU implementations. And whenever domU and dom0
runs under paravirt we fix up to code to remove the #ifdef and add
native mode support.

> >> I think we need either wrapper functions for machine_kexec_* functions
> >> which dispatch to the correct function depending on the environment
> >> (dom0 vs domU, later also native) or just make them function pointers to
> >> archive the same effect.  Same goes for the KEXEC_ARCH_HAS_PAGE_MACROS
> >> stuff.  IMHO "#ifdef CONFIG_XEN" should go away from the core code (i.e.
> >> kernel/kexec.c).
> >
> > You mean for the paravirt stuff?
>
> And domU kexec.  That works without any kexec core changes, and I
> suspect the #ifdef CONFIG_XEN code will break it.
Replacing the #ifdefs with a runtime check that is fine by me. I'm
think it's nice to avoid #ifdefs if possible, but again - our scope of
implementation was simply to add dom0 support. We did not care about
domU support or paravirt that wasn't included at that time.

> > If so, what is stopping us from
> > registering a set of paravirt callbacks for the kexec code?
>
> Hmm, we'll end up with *two* sets of callbacks for xen, one for dom0 and
> one for domU kexec.  Not sure that fits the current paravirt design.
I'm pretty sure that these things will be easy to resolve when the
time is right.

> Given we may move to paravirt some day it's probably best to go with the
> function pointers approach for now, that makes switching over to the
> paravirt infrastructure (once it is mainline) easier.  And I think its
> also less messy in the code.
There is only a point in having function pointers when you have more
than one implementation. And now you are going from one implementation
to two so adding function pointers makes sense. If we would have added
function pointers in our patch it would have been pure bloat because
there was no one there except us to use them.

/ magnus

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