On Fri, Mar 16, 2007 at 06:20:14PM +0900, Magnus Damm wrote:
quoted text
> 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
-
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/