[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] kexec woes with 32-bit secondary kernel



On Fri, 2010-09-17 at 16:49 +0100, Jan Beulich wrote: 
> Ever since c/s 13829, the native (32-bit -> 32-bit) call to invoke the
> secondary kernel has been missing its fourth argument. Apparently
> this worked out because the respective stack location was non-zero.

Which argument is this? 

> Starting with Linux 2.6.27 (32-bit) and 2.6.30 (64-bit) a new
> argument is being expected by the secondary kernel, and again
> apparently out of pure luck the 64-bit -> 64-bit case still appears
> to work for those of our customers who want to use it.
> 
> The question really is whether this code has ever been tested
> with sufficiently recent kernels in all three variants (32->32, 64->64,
> and 64->32).

It gets pretty regular testing in XenServer and XCP in the
32on64->32native variant. This works at least with the 2.6.27 and 2.6.32
domain 0 kernels used in those two situations.

I can't speak for any testing done elsewhere though. I suspect that
other than what you guys do there isn't that much of it.

> While it seems that putting together a patch to address this
> shouldn't be that difficult, a second question is how we can avoid
> getting into the same situation again when Linux extends the
> protocol again.

I've always thought that the hypercall interface is rather too closely
modelled on internals of a particular implementation from a particular
version of Linux. On the other hand I'm not sure I have any better
ideas.

Ian.



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.