Re: kexec trouble

[Gerd Hoffmann <kraxel@suse.de>]

  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.

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

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.

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

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

> 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 ;)

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>