|
|
|
|
|
|
|
|
|
|
xen-devel
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
|
|
|
|
|