Re: [Xen-devel] kexec design issues

[Simon Horman <horms@xxxxxxxxxxxx>]

On Thu, Mar 12, 2009 at 02:49:50PM +0000, Jan Beulich wrote:
> As I became aware of only now (by way of a bug report), Linux side kexec
> changes on i386 silently broke assumptions in the kexec hypercall interface.
> Therefore I'd like to get an understanding on what the general perspective
> on the following problems is:
> 
> 1) machine_kexec_load() silently assumes that page_list[] has alternating
> (and paired) physical/virtual entries. This is no longer valid with 2.6.27, 
> and
> while the immediate fix is to re-arrange the list entries so that the newly
> added entry would end up after all pairs (in 2.6.29 an extra gap will need
> to be added), this points out that the interface definition itself is really
> flawed.
> 
> 2) KEXEC_XEN_NO_PAGES is set to the apparently arbitrary value of 17.
> While a build error would clearly show any incompatible Linux side change
> in this case, it still seems bogus to hard-code this Linux defined value into
> the hypercall interface.
> 
> 3) machine_kexec_load() blindly iterates over all page_list[] entries,
> regardless of whether any of them is zero, and hence establishes
> (currently on 32-bit only) numerous bogus page table entries mapping
> mfn 0.

Hi Jan,

sorry for not replying earlier. I have CCed Magnus Damm who
along with myself was involved in the original port of kexec to Xen.

I must confess that I am bit rusty on the details, but as I recall the
premise of the original design of our port was to allow the existing kexec
functionality to work inside Xen. Not great deal of thought was given to
to anticipating ways that kexec might change in the future.

In reference to questions 1) and 3), all I can really respond with is that
is how kexec worked at that time (IIRC), so it seemed to be logical for xen
to read the data in that way. If its not now, then I am more than happy to
help work towards a better solution.

In reference to question 2), the number 17 is derived from
include/asm-x86_64/kexec.h in the linux-xen 2.6.18 tree as x86_64 has the
highest value for PAGES_NR.  I agree that having this number included in
the hypercall interface isn't ideal.

-- 
Simon Horman
  VA Linux Systems Japan K.K., Sydney, Australia Satellite Office
  H: www.vergenet.net/~horms/             W: www.valinux.co.jp/en


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