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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 17.09.10 at 18:57, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 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? 

The cpu_has_pae one.

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

Hmm, that contradicts what we got told: Neither 32->32native
nor 32on64->32native work. But surely it working for you can be
a simple matter of luck with the compiler version you're using
(pretty likely different from the ones used for SLE).

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

Yeah, I agree with both parts. Probably some sort of signature
of the called code would have helped.

Jan


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