xen-ia64-devel
RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?
To: |
<takebe_akio@xxxxxxxxxxxxxx>, "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>, <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx> |
Subject: |
RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo? |
From: |
"Xu, Anthony" <anthony.xu@xxxxxxxxx> |
Date: |
Tue, 8 Nov 2005 11:00:31 +0800 |
Delivery-date: |
Tue, 08 Nov 2005 03:00:37 +0000 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
List-help: |
<mailto:xen-ia64-devel-request@lists.xensource.com?subject=help> |
List-id: |
Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com> |
List-post: |
<mailto:xen-ia64-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe> |
Sender: |
xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx |
Thread-index: |
AcXkD3C/srEztCcwRRKZccdINq6iZQAAHTzg |
Thread-topic: |
[Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo? |
Akio,
I just remembered xlilo doesn't support compressed guest linux kernel, so you
should use compressed xen.gz and uncompressed guest linux kernel vmlinux, and
compressed initrd.
Thanks
Anthony
>-----Original Message-----
>From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>takebe_akio@xxxxxxxxxxxxxx
>Sent: 2005年11月8日 10:51
>To: takebe_akio@xxxxxxxxxxxxxx; Magenheimer, Dan (HP Labs Fort Collins);
>xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?
>
>Hi All,
>
>I'm still tried to boot RHEL4 + Xen.
>But I have not been able to boot yet.
>
>I confirmed to boot until the following point.
>
>fs/binfmt_elf.c
>-------------------------
> static int load_elf_binary(struct linux_binprm * bprm, struct pt_regs * regs)
> {
>
> snip...
>
> for (i = 0; i < loc->elf_ex.e_phnum; i++) {
> if (elf_ppnt->p_type == PT_INTERP) {
> /* This is the program interpreter used for
> * shared libraries - for now assume that this
> * is an a.out format binary
> */
>
> retval = -ENOEXEC;
> if (elf_ppnt->p_filesz > PATH_MAX ||
> elf_ppnt->p_filesz < 2)
> goto out_free_file;
> retval = -ENOMEM;
> elf_interpreter = (char *)
>kmalloc(elf_ppnt->p_filesz,
> GFP_KERNEL);
> if (!elf_interpreter)
> goto out_free_file;
>
> retval = kernel_read(bprm->file,
>elf_ppnt->p_offset,
> elf_interpreter,
> elf_ppnt->p_filesz);
> if (retval != elf_ppnt->p_filesz) {
> if (retval >= 0)
> retval = -EIO;
> goto out_free_interp;
> }
> /* make sure path is NULL terminated */
> retval = -ENOEXEC;
> if (elf_interpreter[elf_ppnt->p_filesz - 1] != '\0')
> goto out_free_interp;
>
> /* If the program interpreter is one of these two,
> * then assume an iBCS2 image. Otherwise assume
> * a native linux image.
> */
> if (strcmp(elf_interpreter,"/usr/lib/libc.so.1") ==
>0 ||
> strcmp(elf_interpreter,"/usr/lib/ld.so.1") ==
>0)
> ibcs2_interpreter = 1;
>
> /*
> * The early SET_PERSONALITY here is so that the
>lookup
> * for the interpreter happens in the namespace of the
> * to-be-execed image. SET_PERSONALITY can select
>an
> * alternate root.
> *
> * However, SET_PERSONALITY is NOT allowed to switch
> * this task into the new images's memory mapping
> * policy - that is, TASK_SIZE must still evaluate to
> * that which is appropriate to the execing
>application.
> * This is because exit_mmap() needs to have TASK_SIZE
> * evaluate to the size of the old image.
> *
> * So if (say) a 64-bit application is execing a
> 32-bit
> * application it is the architecture's
>responsibility
> * to defer changing the value of TASK_SIZE until the
> * switch really is going to happen - do this in
> * flush_thread(). - akpm
> */
> SET_PERSONALITY(loc->elf_ex, ibcs2_interpreter);
>
> interpreter = open_exec(elf_interpreter);
> retval = PTR_ERR(interpreter);
> if (IS_ERR(interpreter))
> goto out_free_interp;
> retval = kernel_read(interpreter, 0, bprm->buf,
>BINPRM_BUF_SIZE); <---HERE !!!!!
> if (retval != BINPRM_BUF_SIZE) {
> if (retval >= 0)
> retval = -EIO;
> goto out_free_dentry;
> }
>
> /* Get the exec headers */
> loc->interp_ex = *((struct exec *) bprm->buf);
> loc->interp_elf_ex = *((struct elfhdr *) bprm->buf);
> break;
> }
> elf_ppnt++;
> }
> snip...
>-------------
>
>The above for loop is available when there is .interp section in ELF binary.
>.interp section is found, then enter if section and the following operation do.
> 1. Check "if (elf_ppnt->p_filesz > PATH_MAX || elf_ppnt->p_filesz < 2)"
> 2. Alloc memory for pasting a library path by using kmalloc().
> 3. Read a library path from /sbin/init by using kernel_read()
> 4. Check wheather /usr/lib/libc.so.1 or /usr/lib/ld.so.1
> 5. Open the library by using open_exec()
> 6. Read the library from head to BINPRM_BUF_SIZE(128)
> 7. Substitute the library header and Break
>
>contents of .interp section are below.
>=====================
># LANG=C objdump -s -j .interp /sbin/init
>
>/sbin/init: file format elf64-ia64-little
>
>Contents of section .interp:
> 4000000000000200 2f6c6962 2f6c642d 6c696e75 782d6961 /lib/ld-linux-ia
> 4000000000000210 36342e73 6f2e3200 64.so.2.
>=====================
>
> /lib/ld-linux-ia64.so.2 is symbolic link
>=====================
># LANG=C ls -l /lib/ld-linux-ia64.so.2
>lrwxrwxrwx 1 root root 11 Oct 25 23:27 /lib/ld-linux-ia64.so.2 -> ld-2.3.4.so
>=====================
>
>I think 0 -> 128 byte of the ld-2.3.4.so is ELF header.
>The header of the ld-2.3.4.so is the below.
>=====================
># readelf -h /lib/ld-2.3.4.so |less
>ELF Header:
> Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF64
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: DYN (Shared object file)
> Machine: Intel IA-64
> Version: 0x1
> Entry point address: 0x2c90
> Start of program headers: 64 (bytes into file)
> Start of section headers: 205448 (bytes into file)
> Flags: 0x10, 64-bit
> Size of this header: 64 (bytes)
> Size of program headers: 56 (bytes)
> Number of program headers: 5
> Size of section headers: 64 (bytes)
> Number of section headers: 25
> Section header string table index: 22
>=====================
>
>Why the header cannot be read?
>Any idea? It's very difficult. Hmmm.... :<
>
>Best Regards,
>
>Akio takebe
>
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?,
Xu, Anthony <=
- RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Yang, Fred
- RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Yang, Fred
- RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Zhang, Xiantao
- RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Zhang, Xiantao
- RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Magenheimer, Dan (HP Labs Fort Collins)
- RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Yang, Fred
|
Previous by Date: |
RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Magenheimer, Dan (HP Labs Fort Collins) |
Next by Date: |
RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Yang, Fred |
Previous by Thread: |
RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Magenheimer, Dan (HP Labs Fort Collins) |
Next by Thread: |
RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Yang, Fred |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|