| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] kexec woes with 32-bit secondary kernel
>>> 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
|
|
|
| |
|
Home