* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-15 23:48 ` Horms
@ 2007-03-16 2:40 ` Magnus Damm
2007-03-16 3:22 ` Vivek Goyal
2007-03-16 7:28 ` Ian Campbell
2007-03-16 2:42 ` Vivek Goyal
2007-03-16 7:17 ` Ian Campbell
2 siblings, 2 replies; 31+ messages in thread
From: Magnus Damm @ 2007-03-16 2:40 UTC (permalink / raw)
To: Horms; +Cc: Vivek Goyal, fastboot, linux-kernel, Ian Campbell
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 recall kexecing a bzImage for x86_64 on i386, but I'm not 100% sure.
I think it worked because the bzImage loader code was regular 32 bit
x86 code, but that may be wrong as well.
> Won't the above change break non i386 archtectures as
> vmcore_elf_check_arch_cross isn't defined for them?
Right. And maybe it's a good idea to make sure that this feature is
actually supported by kexec-tools before adding code to the kernel?
My gut feeling about this is that you are begging for trouble. The
kexec/kdump solution is fragile just by itself, and trying to go
between architectures is just going to be painful.
/ magnus
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 2:40 ` [Fastboot] " Magnus Damm
@ 2007-03-16 3:22 ` Vivek Goyal
2007-03-16 7:10 ` Horms
2007-03-16 7:28 ` Ian Campbell
1 sibling, 1 reply; 31+ messages in thread
From: Vivek Goyal @ 2007-03-16 3:22 UTC (permalink / raw)
To: Magnus Damm; +Cc: Horms, fastboot, linux-kernel, Ian Campbell
On Fri, Mar 16, 2007 at 11:40:07AM +0900, Magnus Damm wrote:
> 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 3:22 ` Vivek Goyal
@ 2007-03-16 7:10 ` Horms
2007-03-16 7:50 ` Magnus Damm
0 siblings, 1 reply; 31+ messages in thread
From: Horms @ 2007-03-16 7:10 UTC (permalink / raw)
To: Vivek Goyal; +Cc: Magnus Damm, fastboot, linux-kernel, Ian Campbell
On Fri, Mar 16, 2007 at 08:52:30AM +0530, Vivek Goyal wrote:
> On Fri, Mar 16, 2007 at 11:40:07AM +0900, Magnus Damm wrote:
> > 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.
I feel comfortable with that. Well for now anyway.
But I think that Magnus has other ideas.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 7:10 ` Horms
@ 2007-03-16 7:50 ` Magnus Damm
0 siblings, 0 replies; 31+ messages in thread
From: Magnus Damm @ 2007-03-16 7:50 UTC (permalink / raw)
To: Horms; +Cc: Vivek Goyal, fastboot, linux-kernel, Ian Campbell
On 3/16/07, Horms <horms@verge.net.au> wrote:
> On Fri, Mar 16, 2007 at 08:52:30AM +0530, Vivek Goyal wrote:
> > 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.
>
> I feel comfortable with that. Well for now anyway.
> But I think that Magnus has other ideas.
I don't mind switching back and forth between 32-bit and 64-bit for
plain kexec, especially if we can validate that the kernel we load
will use an instruction set that is supported. But for kdump,
switching between 32-bit and 64-bit kernels is just another new
dimension in the already too complex kdump matrix IMO.
I think more focus should be put on fixing up bugs in kexec-tools than
adding new features.
/ magnus
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 2:40 ` [Fastboot] " Magnus Damm
2007-03-16 3:22 ` Vivek Goyal
@ 2007-03-16 7:28 ` Ian Campbell
2007-03-16 7:59 ` Magnus Damm
1 sibling, 1 reply; 31+ messages in thread
From: Ian Campbell @ 2007-03-16 7:28 UTC (permalink / raw)
To: Magnus Damm; +Cc: Horms, Vivek Goyal, fastboot, linux-kernel
On Fri, 2007-03-16 at 11:40 +0900, Magnus Damm wrote:
> Right. And maybe it's a good idea to make sure that this feature is
> actually supported by kexec-tools before adding code to the kernel?
I sent patches to the fastboot list at the same time I sent these ones
to support differences in the underlying hypervisor architecture in the
tools.
They haven't appeared in the archives yet so I fear they have gone
astray. I'll resend when I get to the office in a bit.
The tools already have support for introducing a SHIM when kexecing
between different architectures (at least in the 64->32 direction if I
understand kexec-tools-testing/purgatory/arch/i386/compat_x86_64.S and
k-t-t.../kexec/arch/i386/compat_x86_64.S correctly). This is really just
an extension of that.
> My gut feeling about this is that you are begging for trouble. The
> kexec/kdump solution is fragile just by itself, and trying to go
> between architectures is just going to be painful.
It works fine under Xen and I think going from 64Xen+32Kernel->32Kernel
makes more sense than going from 64Xen+32Kernel->64Kernel. As I said
originally I'm not so convinced it makes sense in the native case but I
see no reason to outlaw it (people get to keep both pieces etc...)
Ian.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 7:28 ` Ian Campbell
@ 2007-03-16 7:59 ` Magnus Damm
2007-03-16 8:50 ` Ian Campbell
0 siblings, 1 reply; 31+ messages in thread
From: Magnus Damm @ 2007-03-16 7:59 UTC (permalink / raw)
To: Ian Campbell; +Cc: Horms, Vivek Goyal, fastboot, linux-kernel
On 3/16/07, Ian Campbell <Ian.Campbell@xensource.com> wrote:
> On Fri, 2007-03-16 at 11:40 +0900, Magnus Damm wrote:
> > Right. And maybe it's a good idea to make sure that this feature is
> > actually supported by kexec-tools before adding code to the kernel?
>
> I sent patches to the fastboot list at the same time I sent these ones
> to support differences in the underlying hypervisor architecture in the
> tools.
Oh, that's good news. I have not seen them yet...
> They haven't appeared in the archives yet so I fear they have gone
> astray. I'll resend when I get to the office in a bit.
... so please resend.
We've just frozen the kexec-tools-testing tree for an upcoming
release, but if you resend soon and your patches are trivial you may
be able to talk us into merging your changes before the release..
> The tools already have support for introducing a SHIM when kexecing
> between different architectures (at least in the 64->32 direction if I
> understand kexec-tools-testing/purgatory/arch/i386/compat_x86_64.S and
> k-t-t.../kexec/arch/i386/compat_x86_64.S correctly). This is really just
> an extension of that.
Right, the mode switching code in purgatory.
> > My gut feeling about this is that you are begging for trouble. The
> > kexec/kdump solution is fragile just by itself, and trying to go
> > between architectures is just going to be painful.
>
> It works fine under Xen and I think going from 64Xen+32Kernel->32Kernel
> makes more sense than going from 64Xen+32Kernel->64Kernel. As I said
> originally I'm not so convinced it makes sense in the native case but I
> see no reason to outlaw it (people get to keep both pieces etc...)
For kexec I think it is just fine. But for kdump, are you sure things
will work out ok? There are some differences between the i386 and
x86_64 kexec-tools code and I wonder if feeding i386 info into an
x86_64 kernel will work properly.
Thanks!
/ magnus
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 7:59 ` Magnus Damm
@ 2007-03-16 8:50 ` Ian Campbell
2007-03-16 9:20 ` Magnus Damm
2007-03-16 9:26 ` Vivek Goyal
0 siblings, 2 replies; 31+ messages in thread
From: Ian Campbell @ 2007-03-16 8:50 UTC (permalink / raw)
To: Magnus Damm; +Cc: Horms, Vivek Goyal, fastboot, linux-kernel
On Fri, 2007-03-16 at 16:59 +0900, Magnus Damm wrote:
> On 3/16/07, Ian Campbell <Ian.Campbell@xensource.com> wrote:
> > On Fri, 2007-03-16 at 11:40 +0900, Magnus Damm wrote:
> > > Right. And maybe it's a good idea to make sure that this feature is
> > > actually supported by kexec-tools before adding code to the kernel?
> >
> > I sent patches to the fastboot list at the same time I sent these ones
> > to support differences in the underlying hypervisor architecture in the
> > tools.
>
> Oh, that's good news. I have not seen them yet...
>
> > They haven't appeared in the archives yet so I fear they have gone
> > astray. I'll resend when I get to the office in a bit.
>
> ... so please resend.
>
> We've just frozen the kexec-tools-testing tree for an upcoming
> release, but if you resend soon and your patches are trivial you may
> be able to talk us into merging your changes before the release..
Will resend in about an hour.
> > > My gut feeling about this is that you are begging for trouble. The
> > > kexec/kdump solution is fragile just by itself, and trying to go
> > > between architectures is just going to be painful.
> >
> > It works fine under Xen and I think going from 64Xen+32Kernel->32Kernel
> > makes more sense than going from 64Xen+32Kernel->64Kernel. As I said
> > originally I'm not so convinced it makes sense in the native case but I
> > see no reason to outlaw it (people get to keep both pieces etc...)
>
> For kexec I think it is just fine. But for kdump, are you sure things
> will work out ok? There are some differences between the i386 and
> x86_64 kexec-tools code and I wonder if feeding i386 info into an
> x86_64 kernel will work properly.
It seems to work fine with Xen. A 32 bit kernel handles the 64 bit dump
just fine, my pre-kdump kernel is 32 bit but it doesn't have much to do
in this case I think.
I don't know about native. My gut feeling is that if the mechanism of
actually kexecing between 64 and 32 bit works then there is no problem
with the crash dump part of the equation.
The crash dump is pretty much opaque to the kernel -- it finds the
headers in memory and exports the relevant pieces via /proc/vmcore. The
crash kernel doesn't really care what those pieces are so long as they
constitute a valid ELF image.
My patch to kexec-tools-testing just changes e_machine to match the type
of the pre-crash system. The dump kernel pays no attention to this field
apart from the one sanity check which my patch from this thread
addresses.
>From userspace the contents of /proc/vmcore should be identical to what
you would see if you had done a 64->64 dump instead of a 64->32 one. I
don't think it is any different to copying /proc/vmcore to a different
system for analysis so any userspace tools should be able to cope.
Ian.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 8:50 ` Ian Campbell
@ 2007-03-16 9:20 ` Magnus Damm
2007-03-16 9:35 ` Vivek Goyal
2007-03-16 9:26 ` Vivek Goyal
1 sibling, 1 reply; 31+ messages in thread
From: Magnus Damm @ 2007-03-16 9:20 UTC (permalink / raw)
To: Ian Campbell; +Cc: Horms, Vivek Goyal, fastboot, linux-kernel
On 3/16/07, Ian Campbell <Ian.Campbell@xensource.com> wrote:
> On Fri, 2007-03-16 at 16:59 +0900, Magnus Damm wrote:
> > On 3/16/07, Ian Campbell <Ian.Campbell@xensource.com> wrote:
> > > On Fri, 2007-03-16 at 11:40 +0900, Magnus Damm wrote:
> > > > Right. And maybe it's a good idea to make sure that this feature is
> > > > actually supported by kexec-tools before adding code to the kernel?
> > >
> > > I sent patches to the fastboot list at the same time I sent these ones
> > > to support differences in the underlying hypervisor architecture in the
> > > tools.
> >
> > Oh, that's good news. I have not seen them yet...
> >
> > > They haven't appeared in the archives yet so I fear they have gone
> > > astray. I'll resend when I get to the office in a bit.
> >
> > ... so please resend.
> >
> > We've just frozen the kexec-tools-testing tree for an upcoming
> > release, but if you resend soon and your patches are trivial you may
> > be able to talk us into merging your changes before the release..
>
> Will resend in about an hour.
>
> > > > My gut feeling about this is that you are begging for trouble. The
> > > > kexec/kdump solution is fragile just by itself, and trying to go
> > > > between architectures is just going to be painful.
> > >
> > > It works fine under Xen and I think going from 64Xen+32Kernel->32Kernel
> > > makes more sense than going from 64Xen+32Kernel->64Kernel. As I said
> > > originally I'm not so convinced it makes sense in the native case but I
> > > see no reason to outlaw it (people get to keep both pieces etc...)
> >
> > For kexec I think it is just fine. But for kdump, are you sure things
> > will work out ok? There are some differences between the i386 and
> > x86_64 kexec-tools code and I wonder if feeding i386 info into an
> > x86_64 kernel will work properly.
>
> It seems to work fine with Xen. A 32 bit kernel handles the 64 bit dump
> just fine, my pre-kdump kernel is 32 bit but it doesn't have much to do
> in this case I think.
>
> I don't know about native. My gut feeling is that if the mechanism of
> actually kexecing between 64 and 32 bit works then there is no problem
> with the crash dump part of the equation.
>
> The crash dump is pretty much opaque to the kernel -- it finds the
> headers in memory and exports the relevant pieces via /proc/vmcore. The
> crash kernel doesn't really care what those pieces are so long as they
> constitute a valid ELF image.
Right, that's how it is supposed to work. But there are unfortunately
differences between the architecture-specific implementations in the
kexec-tools code. So the x86_64 version of kexec-tools behaves
different compared to the i386 version.
For instance, x86_64 passes some acpi parameter on the command line to
the crash kernel, but i386 does not. This may or may not be needed.
There are differences like that or smaller sprinkled all over the
place.
/ magnus
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 9:20 ` Magnus Damm
@ 2007-03-16 9:35 ` Vivek Goyal
2007-03-16 10:05 ` Magnus Damm
0 siblings, 1 reply; 31+ messages in thread
From: Vivek Goyal @ 2007-03-16 9:35 UTC (permalink / raw)
To: Magnus Damm; +Cc: Ian Campbell, Horms, fastboot, linux-kernel
On Fri, Mar 16, 2007 at 06:20:14PM +0900, Magnus Damm wrote:
> On 3/16/07, Ian Campbell <Ian.Campbell@xensource.com> wrote:
> >On Fri, 2007-03-16 at 16:59 +0900, Magnus Damm wrote:
> >> On 3/16/07, Ian Campbell <Ian.Campbell@xensource.com> wrote:
> >> > On Fri, 2007-03-16 at 11:40 +0900, Magnus Damm wrote:
> >> > > Right. And maybe it's a good idea to make sure that this feature is
> >> > > actually supported by kexec-tools before adding code to the kernel?
> >> >
> >> > I sent patches to the fastboot list at the same time I sent these ones
> >> > to support differences in the underlying hypervisor architecture in the
> >> > tools.
> >>
> >> Oh, that's good news. I have not seen them yet...
> >>
> >> > They haven't appeared in the archives yet so I fear they have gone
> >> > astray. I'll resend when I get to the office in a bit.
> >>
> >> ... so please resend.
> >>
> >> We've just frozen the kexec-tools-testing tree for an upcoming
> >> release, but if you resend soon and your patches are trivial you may
> >> be able to talk us into merging your changes before the release..
> >
> >Will resend in about an hour.
> >
> >> > > My gut feeling about this is that you are begging for trouble. The
> >> > > kexec/kdump solution is fragile just by itself, and trying to go
> >> > > between architectures is just going to be painful.
> >> >
> >> > It works fine under Xen and I think going from 64Xen+32Kernel->32Kernel
> >> > makes more sense than going from 64Xen+32Kernel->64Kernel. As I said
> >> > originally I'm not so convinced it makes sense in the native case but I
> >> > see no reason to outlaw it (people get to keep both pieces etc...)
> >>
> >> For kexec I think it is just fine. But for kdump, are you sure things
> >> will work out ok? There are some differences between the i386 and
> >> x86_64 kexec-tools code and I wonder if feeding i386 info into an
> >> x86_64 kernel will work properly.
> >
> >It seems to work fine with Xen. A 32 bit kernel handles the 64 bit dump
> >just fine, my pre-kdump kernel is 32 bit but it doesn't have much to do
> >in this case I think.
> >
> >I don't know about native. My gut feeling is that if the mechanism of
> >actually kexecing between 64 and 32 bit works then there is no problem
> >with the crash dump part of the equation.
> >
> >The crash dump is pretty much opaque to the kernel -- it finds the
> >headers in memory and exports the relevant pieces via /proc/vmcore. The
> >crash kernel doesn't really care what those pieces are so long as they
> >constitute a valid ELF image.
>
> Right, that's how it is supposed to work. But there are unfortunately
> differences between the architecture-specific implementations in the
> kexec-tools code. So the x86_64 version of kexec-tools behaves
> different compared to the i386 version.
>
> For instance, x86_64 passes some acpi parameter on the command line to
> the crash kernel, but i386 does not. This may or may not be needed.
> There are differences like that or smaller sprinkled all over the
> place.
I think passing those acpi parameter to 32bit kernel should not harm.
Got a question. When running 32bit dom0 on 64bit hypervisor, which
kexec-tools elf loader will kick in? 32bit or 64bit? Looks like in this
case 64bit one. But shouldn't it be 32bit as 32bit OS is running and we
must be using the kexec-tools binary compiled for 32bit OS? And if 32bit
loader kicks in we will not be passing any acpi parameters.
Thanks
Vivek
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 9:35 ` Vivek Goyal
@ 2007-03-16 10:05 ` Magnus Damm
2007-03-16 11:38 ` Vivek Goyal
0 siblings, 1 reply; 31+ messages in thread
From: Magnus Damm @ 2007-03-16 10:05 UTC (permalink / raw)
To: vgoyal; +Cc: Ian Campbell, Horms, fastboot, linux-kernel
On 3/16/07, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> Got a question. When running 32bit dom0 on 64bit hypervisor, which
> kexec-tools elf loader will kick in? 32bit or 64bit? Looks like in this
> case 64bit one. But shouldn't it be 32bit as 32bit OS is running and we
> must be using the kexec-tools binary compiled for 32bit OS? And if 32bit
> loader kicks in we will not be passing any acpi parameters.
There is no check to see if the hypervisor is 32 or 64 bits present
today. So the 32-bit version of kexec-tools will support loading
images like any other 32-bit kexec-tools.
Thanks,
/ magnus
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 10:05 ` Magnus Damm
@ 2007-03-16 11:38 ` Vivek Goyal
2007-03-16 11:40 ` Ian Campbell
0 siblings, 1 reply; 31+ messages in thread
From: Vivek Goyal @ 2007-03-16 11:38 UTC (permalink / raw)
To: Magnus Damm; +Cc: Ian Campbell, Horms, fastboot, linux-kernel
On Fri, Mar 16, 2007 at 07:05:30PM +0900, Magnus Damm wrote:
> On 3/16/07, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> >Got a question. When running 32bit dom0 on 64bit hypervisor, which
> >kexec-tools elf loader will kick in? 32bit or 64bit? Looks like in this
> >case 64bit one. But shouldn't it be 32bit as 32bit OS is running and we
> >must be using the kexec-tools binary compiled for 32bit OS? And if 32bit
> >loader kicks in we will not be passing any acpi parameters.
>
> There is no check to see if the hypervisor is 32 or 64 bits present
> today. So the 32-bit version of kexec-tools will support loading
> images like any other 32-bit kexec-tools.
>
If that is the case then in prepared elf headers, machine type should
be EM_386 or similar and not EM_X86_64 and Ian shouldn't have run into
the problem at all with vmcore. Am I missing something?
Thanks
Vivek
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 11:38 ` Vivek Goyal
@ 2007-03-16 11:40 ` Ian Campbell
2007-03-16 12:25 ` Vivek Goyal
0 siblings, 1 reply; 31+ messages in thread
From: Ian Campbell @ 2007-03-16 11:40 UTC (permalink / raw)
To: vgoyal; +Cc: Magnus Damm, Horms, fastboot, linux-kernel
On Fri, 2007-03-16 at 17:08 +0530, Vivek Goyal wrote:
> On Fri, Mar 16, 2007 at 07:05:30PM +0900, Magnus Damm wrote:
> > On 3/16/07, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> > >Got a question. When running 32bit dom0 on 64bit hypervisor, which
> > >kexec-tools elf loader will kick in? 32bit or 64bit? Looks like in this
> > >case 64bit one. But shouldn't it be 32bit as 32bit OS is running and we
> > >must be using the kexec-tools binary compiled for 32bit OS? And if 32bit
> > >loader kicks in we will not be passing any acpi parameters.
> >
> > There is no check to see if the hypervisor is 32 or 64 bits present
> > today. So the 32-bit version of kexec-tools will support loading
> > images like any other 32-bit kexec-tools.
> >
>
> If that is the case then in prepared elf headers, machine type should
> be EM_386 or similar and not EM_X86_64 and Ian shouldn't have run into
> the problem at all with vmcore. Am I missing something?
The PRSTATUS ELF notes are generated by the hypervisor not by the kernel
so they are in 64 bit format in this scenario. The machine type should
reflect this.
Ian.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 11:40 ` Ian Campbell
@ 2007-03-16 12:25 ` Vivek Goyal
2007-03-16 12:31 ` Vivek Goyal
0 siblings, 1 reply; 31+ messages in thread
From: Vivek Goyal @ 2007-03-16 12:25 UTC (permalink / raw)
To: Ian Campbell; +Cc: Magnus Damm, Horms, fastboot, linux-kernel
On Fri, Mar 16, 2007 at 11:40:55AM +0000, Ian Campbell wrote:
> On Fri, 2007-03-16 at 17:08 +0530, Vivek Goyal wrote:
> > On Fri, Mar 16, 2007 at 07:05:30PM +0900, Magnus Damm wrote:
> > > On 3/16/07, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> > > >Got a question. When running 32bit dom0 on 64bit hypervisor, which
> > > >kexec-tools elf loader will kick in? 32bit or 64bit? Looks like in this
> > > >case 64bit one. But shouldn't it be 32bit as 32bit OS is running and we
> > > >must be using the kexec-tools binary compiled for 32bit OS? And if 32bit
> > > >loader kicks in we will not be passing any acpi parameters.
> > >
> > > There is no check to see if the hypervisor is 32 or 64 bits present
> > > today. So the 32-bit version of kexec-tools will support loading
> > > images like any other 32-bit kexec-tools.
> > >
> >
> > If that is the case then in prepared elf headers, machine type should
> > be EM_386 or similar and not EM_X86_64 and Ian shouldn't have run into
> > the problem at all with vmcore. Am I missing something?
>
> The PRSTATUS ELF notes are generated by the hypervisor not by the kernel
> so they are in 64 bit format in this scenario. The machine type should
> reflect this.
>
But ELF header is created in 32bit OS and pre-loaded. At creating time,
32bit kexec-tools will put machine info as EM_386. Who changes it to
EM_X86_64 before vmcore code does a sanity check on it using
elf_chcek_arch()? Does hypervisor fiddle around with this field?
Thanks
Vivek
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 12:25 ` Vivek Goyal
@ 2007-03-16 12:31 ` Vivek Goyal
0 siblings, 0 replies; 31+ messages in thread
From: Vivek Goyal @ 2007-03-16 12:31 UTC (permalink / raw)
To: Ian Campbell; +Cc: Magnus Damm, Horms, fastboot, linux-kernel
On Fri, Mar 16, 2007 at 05:55:59PM +0530, Vivek Goyal wrote:
> On Fri, Mar 16, 2007 at 11:40:55AM +0000, Ian Campbell wrote:
> > On Fri, 2007-03-16 at 17:08 +0530, Vivek Goyal wrote:
> > > On Fri, Mar 16, 2007 at 07:05:30PM +0900, Magnus Damm wrote:
> > > > On 3/16/07, Vivek Goyal <vgoyal@in.ibm.com> wrote:
> > > > >Got a question. When running 32bit dom0 on 64bit hypervisor, which
> > > > >kexec-tools elf loader will kick in? 32bit or 64bit? Looks like in this
> > > > >case 64bit one. But shouldn't it be 32bit as 32bit OS is running and we
> > > > >must be using the kexec-tools binary compiled for 32bit OS? And if 32bit
> > > > >loader kicks in we will not be passing any acpi parameters.
> > > >
> > > > There is no check to see if the hypervisor is 32 or 64 bits present
> > > > today. So the 32-bit version of kexec-tools will support loading
> > > > images like any other 32-bit kexec-tools.
> > > >
> > >
> > > If that is the case then in prepared elf headers, machine type should
> > > be EM_386 or similar and not EM_X86_64 and Ian shouldn't have run into
> > > the problem at all with vmcore. Am I missing something?
> >
> > The PRSTATUS ELF notes are generated by the hypervisor not by the kernel
> > so they are in 64 bit format in this scenario. The machine type should
> > reflect this.
> >
>
> But ELF header is created in 32bit OS and pre-loaded. At creating time,
> 32bit kexec-tools will put machine info as EM_386. Who changes it to
> EM_X86_64 before vmcore code does a sanity check on it using
> elf_chcek_arch()? Does hypervisor fiddle around with this field?
>
Ok. Just now looked at your kexec-tools patch to determine the Xen
capabilities and then filling the machine type accordingly. That explains
why machine type will appear as EM_X86_64.
Thanks
Vivek
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 8:50 ` Ian Campbell
2007-03-16 9:20 ` Magnus Damm
@ 2007-03-16 9:26 ` Vivek Goyal
1 sibling, 0 replies; 31+ messages in thread
From: Vivek Goyal @ 2007-03-16 9:26 UTC (permalink / raw)
To: Ian Campbell; +Cc: Magnus Damm, Horms, fastboot, linux-kernel
On Fri, Mar 16, 2007 at 08:50:01AM +0000, Ian Campbell wrote:
> On Fri, 2007-03-16 at 16:59 +0900, Magnus Damm wrote:
> > On 3/16/07, Ian Campbell <Ian.Campbell@xensource.com> wrote:
> > > On Fri, 2007-03-16 at 11:40 +0900, Magnus Damm wrote:
> > > > Right. And maybe it's a good idea to make sure that this feature is
> > > > actually supported by kexec-tools before adding code to the kernel?
> > >
> > > I sent patches to the fastboot list at the same time I sent these ones
> > > to support differences in the underlying hypervisor architecture in the
> > > tools.
> >
> > Oh, that's good news. I have not seen them yet...
> >
> > > They haven't appeared in the archives yet so I fear they have gone
> > > astray. I'll resend when I get to the office in a bit.
> >
> > ... so please resend.
> >
> > We've just frozen the kexec-tools-testing tree for an upcoming
> > release, but if you resend soon and your patches are trivial you may
> > be able to talk us into merging your changes before the release..
>
> Will resend in about an hour.
>
> > > > My gut feeling about this is that you are begging for trouble. The
> > > > kexec/kdump solution is fragile just by itself, and trying to go
> > > > between architectures is just going to be painful.
> > >
> > > It works fine under Xen and I think going from 64Xen+32Kernel->32Kernel
> > > makes more sense than going from 64Xen+32Kernel->64Kernel. As I said
> > > originally I'm not so convinced it makes sense in the native case but I
> > > see no reason to outlaw it (people get to keep both pieces etc...)
> >
> > For kexec I think it is just fine. But for kdump, are you sure things
> > will work out ok? There are some differences between the i386 and
> > x86_64 kexec-tools code and I wonder if feeding i386 info into an
> > x86_64 kernel will work properly.
>
> It seems to work fine with Xen. A 32 bit kernel handles the 64 bit dump
> just fine, my pre-kdump kernel is 32 bit but it doesn't have much to do
> in this case I think.
>
> I don't know about native. My gut feeling is that if the mechanism of
> actually kexecing between 64 and 32 bit works then there is no problem
> with the crash dump part of the equation.
>
I also think so. If kexec works then kdump should work too. There might
be small issues here and there but can't think of any major one.
Thanks
Vivek
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-15 23:48 ` Horms
2007-03-16 2:40 ` [Fastboot] " Magnus Damm
@ 2007-03-16 2:42 ` Vivek Goyal
2007-03-16 7:31 ` Ian Campbell
2007-03-16 7:17 ` Ian Campbell
2 siblings, 1 reply; 31+ messages in thread
From: Vivek Goyal @ 2007-03-16 2:42 UTC (permalink / raw)
To: Horms; +Cc: Ian Campbell, hbabu, fastboot, linux-kernel, Magnus Damm
On Fri, Mar 16, 2007 at 08:48:08AM +0900, Horms 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.
>
Yesterday I tested it. I could kexec from 64->32bit but not vice versa.
kexec-tools itself gave error message.
"Cannot determine the file type of ../x86_64-vmlinux/vmlinux"
I did not investigate deeper but I got a basic question. How will kexec
know that underlying 32bit machine supports 64bit extensions or not? Do
we allow loading 64bit kernel even underlying machine might not support
it?
Probably you can also give it a try.
> > > > So how about something like vmcore_elf_allowed_cross_arch()? Vmcore
> > > > code can continue to check elf_check_arch() and if that fails it can
> > > > invoke vmcore_elf_allowed_cross_arch() to find out what cross arch are
> > > > allowed for vmcore.
> > >
> > > Something like this?
> > >
> > > Ian.
> > >
> > > ---
> > >
> > > Allow i386 crash kernels to handle x86_64 dumps.
> > >
> > > The specific case I am encountering is kdump under Xen with a 64 bit
> > > hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit
> > > due to the hypervisor but the dump kernel is 32 bit in for maximum
> > > compatibility.
> > >
> > > It's possibly less likely to be useful in a purely native scenario but
> > > I see no reason to disallow it.
> > >
> > > Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
> > >
> > > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> > > index d960507..523e109 100644
> > > --- a/fs/proc/vmcore.c
> > > +++ b/fs/proc/vmcore.c
> > > @@ -514,7 +514,7 @@ static int __init parse_crash_elf64_headers(void)
> > > /* Do some basic Verification. */
> > > if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
> > > (ehdr.e_type != ET_CORE) ||
> > > - !elf_check_arch(&ehdr) ||
> > > + !vmcore_elf_check_arch(&ehdr) ||
> > > ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
> > > ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
> > > ehdr.e_version != EV_CURRENT ||
> > > diff --git a/include/asm-i386/kexec.h b/include/asm-i386/kexec.h
> > > index 4dfc9f5..c76737e 100644
> > > --- a/include/asm-i386/kexec.h
> > > +++ b/include/asm-i386/kexec.h
> > > @@ -47,6 +47,9 @@
> > > /* The native architecture */
> > > #define KEXEC_ARCH KEXEC_ARCH_386
> > >
> > > +/* We can also handle crash dumps from 64 bit kernel. */
> > > +#define vmcore_elf_check_arch_cross(x) ((x)->e_machine == EM_X86_64)
> > > +
> >
> > Ideal place for this probably should have been arch dependent crash_dump.h
> > file. But we don't have one and no point introducing one just for this
> > macro.
> >
> > This change looks good to me.
>
> Won't the above change break non i386 archtectures as
> vmcore_elf_check_arch_cross isn't defined for them?
>
In original patch he has put an arch independent definition in
include/linux/crash_dump.h which will make sure it is not broken on
other architectures.
Thanks
Vivek
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 2:42 ` Vivek Goyal
@ 2007-03-16 7:31 ` Ian Campbell
0 siblings, 0 replies; 31+ messages in thread
From: Ian Campbell @ 2007-03-16 7:31 UTC (permalink / raw)
To: vgoyal; +Cc: Horms, hbabu, fastboot, linux-kernel, Magnus Damm
On Fri, 2007-03-16 at 08:12 +0530, Vivek Goyal wrote:
> I did not investigate deeper but I got a basic question. How will kexec
> know that underlying 32bit machine supports 64bit extensions or not?
It looks like /proc/cpuinfo flags contains "lm" (which is long mode,
right?) even if the machine is running 32 bit mode.
Ian.
^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-15 23:48 ` Horms
2007-03-16 2:40 ` [Fastboot] " Magnus Damm
2007-03-16 2:42 ` Vivek Goyal
@ 2007-03-16 7:17 ` Ian Campbell
2007-03-16 7:30 ` Horms
2 siblings, 1 reply; 31+ messages in thread
From: Ian Campbell @ 2007-03-16 7:17 UTC (permalink / raw)
To: Horms; +Cc: Vivek Goyal, hbabu, fastboot, linux-kernel, Magnus Damm
On Fri, 2007-03-16 at 08:48 +0900, Horms wrote:
> > >
> > > Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
> > >
> > > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> > > index d960507..523e109 100644
> > > --- a/fs/proc/vmcore.c
> > > +++ b/fs/proc/vmcore.c
> > > @@ -514,7 +514,7 @@ static int __init parse_crash_elf64_headers(void)
> > > /* Do some basic Verification. */
> > > if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
> > > (ehdr.e_type != ET_CORE) ||
> > > - !elf_check_arch(&ehdr) ||
> > > + !vmcore_elf_check_arch(&ehdr) ||
> > > ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
> > > ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
> > > ehdr.e_version != EV_CURRENT ||
> > > diff --git a/include/asm-i386/kexec.h b/include/asm-i386/kexec.h
> > > index 4dfc9f5..c76737e 100644
> > > --- a/include/asm-i386/kexec.h
> > > +++ b/include/asm-i386/kexec.h
> > > @@ -47,6 +47,9 @@
> > > /* The native architecture */
> > > #define KEXEC_ARCH KEXEC_ARCH_386
> > >
> > > +/* We can also handle crash dumps from 64 bit kernel. */
> > > +#define vmcore_elf_check_arch_cross(x) ((x)->e_machine == EM_X86_64)
> > > +
> >
> > Ideal place for this probably should have been arch dependent crash_dump.h
> > file. But we don't have one and no point introducing one just for this
> > macro.
> >
> > This change looks good to me.
>
> Won't the above change break non i386 archtectures as
> vmcore_elf_check_arch_cross isn't defined for them?
No, because of this hunk:
diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h
index 3250365..db60dac 100644
--- a/include/linux/crash_dump.h
+++ b/include/linux/crash_dump.h
@@ -14,5 +14,13 @@ extern ssize_t copy_oldmem_page(unsigned long, char *, size_t,
extern const struct file_operations proc_vmcore_operations;
extern struct proc_dir_entry *proc_vmcore;
+/* Architecture code defines this if there are other possible ELF
+ * machine types, e.g. on bi-arch capable hardware. */
+#ifndef vmcore_elf_check_arch_cross(x)
+#define vmcore_elf_check_arch_cross(x) 0
+#endif
[snip]
^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps
2007-03-16 7:17 ` Ian Campbell
@ 2007-03-16 7:30 ` Horms
0 siblings, 0 replies; 31+ messages in thread
From: Horms @ 2007-03-16 7:30 UTC (permalink / raw)
To: Ian Campbell; +Cc: Vivek Goyal, hbabu, fastboot, linux-kernel, Magnus Damm
On Fri, Mar 16, 2007 at 07:17:43AM +0000, Ian Campbell wrote:
> On Fri, 2007-03-16 at 08:48 +0900, Horms wrote:
> > > >
> > > > Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
> > > >
> > > > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> > > > index d960507..523e109 100644
> > > > --- a/fs/proc/vmcore.c
> > > > +++ b/fs/proc/vmcore.c
> > > > @@ -514,7 +514,7 @@ static int __init parse_crash_elf64_headers(void)
> > > > /* Do some basic Verification. */
> > > > if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
> > > > (ehdr.e_type != ET_CORE) ||
> > > > - !elf_check_arch(&ehdr) ||
> > > > + !vmcore_elf_check_arch(&ehdr) ||
> > > > ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
> > > > ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
> > > > ehdr.e_version != EV_CURRENT ||
> > > > diff --git a/include/asm-i386/kexec.h b/include/asm-i386/kexec.h
> > > > index 4dfc9f5..c76737e 100644
> > > > --- a/include/asm-i386/kexec.h
> > > > +++ b/include/asm-i386/kexec.h
> > > > @@ -47,6 +47,9 @@
> > > > /* The native architecture */
> > > > #define KEXEC_ARCH KEXEC_ARCH_386
> > > >
> > > > +/* We can also handle crash dumps from 64 bit kernel. */
> > > > +#define vmcore_elf_check_arch_cross(x) ((x)->e_machine == EM_X86_64)
> > > > +
> > >
> > > Ideal place for this probably should have been arch dependent crash_dump.h
> > > file. But we don't have one and no point introducing one just for this
> > > macro.
> > >
> > > This change looks good to me.
> >
> > Won't the above change break non i386 archtectures as
> > vmcore_elf_check_arch_cross isn't defined for them?
>
> No, because of this hunk:
Thanks, silly me :(
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
^ permalink raw reply [flat|nested] 31+ messages in thread