On Fri, Mar 16, 2007 at 11:40:07AM +0900, Magnus Damm wrote:
quoted text
> On 3/16/07, Horms <horms@verge.net.au> wrote:
> >On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> >> On Thu, Mar 15, 2007 at 12:22:57PM +0000, Ian Campbell wrote:
> >> > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> >> > > > > But I think changing this macro might run into issues. It is
> >> > > > > being used at few places in kernel, for example while loading
> >> > > > > module. This will essentially mean that we allow loading 64bit
> >> > > > > x86_64 modules on 32bit i386 systems?
> >> >
> >> > Yes, not sure how I missed that fact...
> >> >
> >> > > Kexec will also not allow loading an x86_64 kernel on a 32bit 
> >machine.
> >> >
> >> > For crash kernel only or for regular kexec too?
> >> >
> >>
> >> I think for both. One of the possible reasons I think is that one never
> >> knows is underlying machine has got 64bit extensions or not. So even if
> >> we load the kernel it will never boot. Secondly, we might not be able to
> >> handle 64bit address in 32bit kernel/user space?
> >
> >Perhaps I am miss-understanding what you are saying, but I do
> >recally kexecing from 32->64 and 64->32 bit kernels on x86_64 hardware.
> >I can run these checks again if it helps.
> 

I stand corrected. I can kexec an bzImage 32->64bit. That's a different
thing that it ran into some initrd issues later but fundamentally kexec
could load 64bit kernel bzImage and do the successful transition.

So it will now be left to the user. If he tries to kexec to a 64bit kernel
on a machine not supporting 32bit extensions, then kexec will not give
any advance warning.

Thanks
Vivek
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/