Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On Thu, Nov 22, 2012 at 3:27 AM, Eric W. Biederman wrote: > "H. Peter Anvin" writes: > >> Quite certain something depends on it. > > It would not surprise me at all that there is a dependency, if we have > not had a better way to report the 64bit entry point. I just wanted to > make the context clear as that was confused in the discussion. > > Note that having a 32bit entry point at offset 0 is as much of an ABI. > > I am surprised that there are legitimate reasons to bulk up the 32bit > entry point code before the 0x200. Everything that we are doing at that > point is architectural. arch/x86/boot/header.S has bzImage 16 bit entry, and it is 0x200 arch/x86/boot/compressed/head_64.S has bzImage 32bit entry and 64bit entry. loader need to find out the setup_code size at first aka kern16_size. then from kern16_size will be 32bit code/64 bit code, will be aligned to kernel_align then from there 0: will be 32bit entry, 0x200 will be 64bit entry. Actually kexec does not support bzImage booting directly from 64bit before this patch set. So are there any 64 bit boot loader that load bzImage and boot directly from that second 0x200 64 bit entry ? If there is no such bootloader there, we may change that position, and add one field in setup_header for it. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On Thu, Nov 22, 2012 at 3:27 AM, Eric W. Biederman ebied...@xmission.com wrote: H. Peter Anvin h...@zytor.com writes: Quite certain something depends on it. It would not surprise me at all that there is a dependency, if we have not had a better way to report the 64bit entry point. I just wanted to make the context clear as that was confused in the discussion. Note that having a 32bit entry point at offset 0 is as much of an ABI. I am surprised that there are legitimate reasons to bulk up the 32bit entry point code before the 0x200. Everything that we are doing at that point is architectural. arch/x86/boot/header.S has bzImage 16 bit entry, and it is 0x200 arch/x86/boot/compressed/head_64.S has bzImage 32bit entry and 64bit entry. loader need to find out the setup_code size at first aka kern16_size. then from kern16_size will be 32bit code/64 bit code, will be aligned to kernel_align then from there 0: will be 32bit entry, 0x200 will be 64bit entry. Actually kexec does not support bzImage booting directly from 64bit before this patch set. So are there any 64 bit boot loader that load bzImage and boot directly from that second 0x200 64 bit entry ? If there is no such bootloader there, we may change that position, and add one field in setup_header for it. Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
Yinghai Lu writes: > On Wed, Nov 21, 2012 at 11:50 AM, H. Peter Anvin wrote: >> The comment is just plain wrong. It assumes you're loading an ELF file, >> whereas in practice that is rarely true. >> >> This does explain why the poor ABI, though. A jump table at the >> beginning would have been a lot cleaner. > > Can you please have patch to update the comments and point to the API there ? Long ago and far away. I wrote the 64bit entry code for a bzImage by putting an ELF header in the boot sector. That is what that comment referred to when it was written. Andrew had a problem on one of his test machines and so the patch to bootsector was dropped. Booting with a vmlinux file does (or at least should not) need this. ELF loaders will pick the entry point out from the ELF header. I don't know what has happened in the intervening time, or who if anyone has depended on that offset. The original intent an internal use hard code. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
"H. Peter Anvin" writes: > Quite certain something depends on it. It would not surprise me at all that there is a dependency, if we have not had a better way to report the 64bit entry point. I just wanted to make the context clear as that was confused in the discussion. Note that having a 32bit entry point at offset 0 is as much of an ABI. I am surprised that there are legitimate reasons to bulk up the 32bit entry point code before the 0x200. Everything that we are doing at that point is architectural. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
H. Peter Anvin h...@zytor.com writes: Quite certain something depends on it. It would not surprise me at all that there is a dependency, if we have not had a better way to report the 64bit entry point. I just wanted to make the context clear as that was confused in the discussion. Note that having a 32bit entry point at offset 0 is as much of an ABI. I am surprised that there are legitimate reasons to bulk up the 32bit entry point code before the 0x200. Everything that we are doing at that point is architectural. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
Yinghai Lu ying...@kernel.org writes: On Wed, Nov 21, 2012 at 11:50 AM, H. Peter Anvin h...@zytor.com wrote: The comment is just plain wrong. It assumes you're loading an ELF file, whereas in practice that is rarely true. This does explain why the poor ABI, though. A jump table at the beginning would have been a lot cleaner. Can you please have patch to update the comments and point to the API there ? Long ago and far away. I wrote the 64bit entry code for a bzImage by putting an ELF header in the boot sector. That is what that comment referred to when it was written. Andrew had a problem on one of his test machines and so the patch to bootsector was dropped. Booting with a vmlinux file does (or at least should not) need this. ELF loaders will pick the entry point out from the ELF header. I don't know what has happened in the intervening time, or who if anyone has depended on that offset. The original intent an internal use hard code. Eric -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On Wed, Nov 21, 2012 at 11:50 AM, H. Peter Anvin wrote: > The comment is just plain wrong. It assumes you're loading an ELF file, > whereas in practice that is rarely true. > > This does explain why the poor ABI, though. A jump table at the > beginning would have been a lot cleaner. Can you please have patch to update the comments and point to the API there ? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On 11/21/2012 11:45 AM, Yinghai Lu wrote: > On Wed, Nov 21, 2012 at 9:23 AM, H. Peter Anvin wrote: >> On 11/20/2012 11:15 PM, Yinghai Lu wrote: >>> >>> We are short of space before 0x200 that is entry for startup_64. >>> >>> And we can not change startup_64 to other value --- ABI ? >> >> >> Here you are saying "I don't understand how this works." It is YOUR >> responsibility to find out and write a definite statement rather than >> leaving that to the reader, or expect the maintainer to edit this. > > actually, i can not find that out. > in the code of arch/x86/boot/compressed/head_64.S > > /* > * Be careful here startup_64 needs to be at a predictable > * address so I can export it in an ELF header. Bootloaders > * should look at the ELF header to find this address, as > * it may change in the future. > */ > .code64 > .org 0x200 > ENTRY(startup_64) > /* > * We come here either from startup_32 or directly from a > * 64bit bootloader. If we come here from a bootloader we depend on > * an identity mapped page table being provied that maps our > * entire text+data+bss and hopefully all of memory. > */ > #ifdef CONFIG_EFI_STUB > /* > * The entry point for the PE/COFF executable is 0x210, so only > * legacy boot loaders will execute this jmp. > */ > jmp preferred_addr > > .org 0x210 > mov %rcx, %rdi > > and it says that 0x200 will be changed later.. > > so you said it has to stay with 0x200, do you mean 0x210 from PE/COFF > force that? > > wonder if you are considering attatched patch to move startup_64 down... > we could kill one jmp. > The comment is just plain wrong. It assumes you're loading an ELF file, whereas in practice that is rarely true. This does explain why the poor ABI, though. A jump table at the beginning would have been a lot cleaner. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On Wed, Nov 21, 2012 at 9:23 AM, H. Peter Anvin wrote: > On 11/20/2012 11:15 PM, Yinghai Lu wrote: >> >> We are short of space before 0x200 that is entry for startup_64. >> >> And we can not change startup_64 to other value --- ABI ? > > > Here you are saying "I don't understand how this works." It is YOUR > responsibility to find out and write a definite statement rather than > leaving that to the reader, or expect the maintainer to edit this. actually, i can not find that out. in the code of arch/x86/boot/compressed/head_64.S /* * Be careful here startup_64 needs to be at a predictable * address so I can export it in an ELF header. Bootloaders * should look at the ELF header to find this address, as * it may change in the future. */ .code64 .org 0x200 ENTRY(startup_64) /* * We come here either from startup_32 or directly from a * 64bit bootloader. If we come here from a bootloader we depend on * an identity mapped page table being provied that maps our * entire text+data+bss and hopefully all of memory. */ #ifdef CONFIG_EFI_STUB /* * The entry point for the PE/COFF executable is 0x210, so only * legacy boot loaders will execute this jmp. */ jmp preferred_addr .org 0x210 mov %rcx, %rdi and it says that 0x200 will be changed later.. so you said it has to stay with 0x200, do you mean 0x210 from PE/COFF force that? wonder if you are considering attatched patch to move startup_64 down... we could kill one jmp. Thanks Yinghai new_startup_64_0x400.patch Description: Binary data
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On 11/20/2012 11:15 PM, Yinghai Lu wrote: We are short of space before 0x200 that is entry for startup_64. And we can not change startup_64 to other value --- ABI ? Here you are saying "I don't understand how this works." It is YOUR responsibility to find out and write a definite statement rather than leaving that to the reader, or expect the maintainer to edit this. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On 11/20/2012 11:15 PM, Yinghai Lu wrote: We are short of space before 0x200 that is entry for startup_64. And we can not change startup_64 to other value --- ABI ? Here you are saying I don't understand how this works. It is YOUR responsibility to find out and write a definite statement rather than leaving that to the reader, or expect the maintainer to edit this. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On Wed, Nov 21, 2012 at 9:23 AM, H. Peter Anvin h...@zytor.com wrote: On 11/20/2012 11:15 PM, Yinghai Lu wrote: We are short of space before 0x200 that is entry for startup_64. And we can not change startup_64 to other value --- ABI ? Here you are saying I don't understand how this works. It is YOUR responsibility to find out and write a definite statement rather than leaving that to the reader, or expect the maintainer to edit this. actually, i can not find that out. in the code of arch/x86/boot/compressed/head_64.S /* * Be careful here startup_64 needs to be at a predictable * address so I can export it in an ELF header. Bootloaders * should look at the ELF header to find this address, as * it may change in the future. */ .code64 .org 0x200 ENTRY(startup_64) /* * We come here either from startup_32 or directly from a * 64bit bootloader. If we come here from a bootloader we depend on * an identity mapped page table being provied that maps our * entire text+data+bss and hopefully all of memory. */ #ifdef CONFIG_EFI_STUB /* * The entry point for the PE/COFF executable is 0x210, so only * legacy boot loaders will execute this jmp. */ jmp preferred_addr .org 0x210 mov %rcx, %rdi and it says that 0x200 will be changed later.. so you said it has to stay with 0x200, do you mean 0x210 from PE/COFF force that? wonder if you are considering attatched patch to move startup_64 down... we could kill one jmp. Thanks Yinghai new_startup_64_0x400.patch Description: Binary data
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On 11/21/2012 11:45 AM, Yinghai Lu wrote: On Wed, Nov 21, 2012 at 9:23 AM, H. Peter Anvin h...@zytor.com wrote: On 11/20/2012 11:15 PM, Yinghai Lu wrote: We are short of space before 0x200 that is entry for startup_64. And we can not change startup_64 to other value --- ABI ? Here you are saying I don't understand how this works. It is YOUR responsibility to find out and write a definite statement rather than leaving that to the reader, or expect the maintainer to edit this. actually, i can not find that out. in the code of arch/x86/boot/compressed/head_64.S /* * Be careful here startup_64 needs to be at a predictable * address so I can export it in an ELF header. Bootloaders * should look at the ELF header to find this address, as * it may change in the future. */ .code64 .org 0x200 ENTRY(startup_64) /* * We come here either from startup_32 or directly from a * 64bit bootloader. If we come here from a bootloader we depend on * an identity mapped page table being provied that maps our * entire text+data+bss and hopefully all of memory. */ #ifdef CONFIG_EFI_STUB /* * The entry point for the PE/COFF executable is 0x210, so only * legacy boot loaders will execute this jmp. */ jmp preferred_addr .org 0x210 mov %rcx, %rdi and it says that 0x200 will be changed later.. so you said it has to stay with 0x200, do you mean 0x210 from PE/COFF force that? wonder if you are considering attatched patch to move startup_64 down... we could kill one jmp. The comment is just plain wrong. It assumes you're loading an ELF file, whereas in practice that is rarely true. This does explain why the poor ABI, though. A jump table at the beginning would have been a lot cleaner. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 01/12] x86, boot: move verify_cpu.S after 0x200
On Wed, Nov 21, 2012 at 11:50 AM, H. Peter Anvin h...@zytor.com wrote: The comment is just plain wrong. It assumes you're loading an ELF file, whereas in practice that is rarely true. This does explain why the poor ABI, though. A jump table at the beginning would have been a lot cleaner. Can you please have patch to update the comments and point to the API there ? Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
