Re: [Xen-devel] kexec trouble

[Gerd Hoffmann <kraxel@xxxxxxx>]

  Hi,

>> IMHO the kexec code makes way to many decisions at compile time, not
>> runtime, especially the ones in the kexec code core.  Having something
>> depend on CONFIG_XEN doesn't fly with the paravirt approach planned for
>> mainline merge (same kernel binary runs both native and paravirtualized).
> 
> Sure, but isn't the paravirt stuff just for domU first to begin with?

domU only as first step, later dom0 too.

> I'm pretty sure that making the code dynamically decide between dom0,
> domU or native is quite simple to implement when it comes to kexec,
> but I wanted to wait with that until most parts of dom0 was running
> under paravirt.

I'd prefer to do that _now_.

>> 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.

>> 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.

> Isn't paravirt basically a set of
> callbacks that you can register?

Yes.

> 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.

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.

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@xxxxxxx>

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