[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |