Re: [Xen-devel] kexec trouble

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

Hi Gerd,

On 12/5/06, Gerd Hoffmann <kraxel@xxxxxxx> wrote:
>   Hi,
>
> Uh, it's a bit messy, with the changes sprinkled over the sparse tree
> and the patches directory, which makes it a bit hard to fixup stuff.
Well, I'm sorry to hear that you think it is messy. I don't think that
we touch that many places in the sparse tree, but I agree that the
combination of patches and sparse may be a bit confusing. The
alternative to patches would have been to duplicate the files by
copying the into the sparse tree which I wanted to avoid because I
think it makes future up porting difficult.

> 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?
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'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? They
are in include/linux/kexec.h if I'm not mistaken. In a patch, not in
sparse.

> 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? Isn't paravirt basically a set of
callbacks that you can register? If so, what is stopping us from
registering a set of paravirt callbacks for the kexec code?

/ magnus

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