Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps

[Vivek Goyal]

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@xxxxxxxxxx> 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

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