Messages in this thread | | | Date | Fri, 16 Mar 2007 17:55:59 +0530 | From | Vivek Goyal <> | Subject | Re: [Fastboot] [PATCH 1/1] Allow i386 crash kernels to handle x86_64 dumps |
| |
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
- 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/
| |