xen-ia64-devel
RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?
To: |
"Xu, Anthony" <anthony.xu@xxxxxxxxx>, <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: |
"Yang, Fred" <fred.yang@xxxxxxxxx> |
Date: |
Mon, 7 Nov 2005 19:10:03 -0800 |
Delivery-date: |
Tue, 08 Nov 2005 03:10:17 +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/srEztCcwRRKZccdINq6iZQAAHTzgAABY1BA= |
Thread-topic: |
[Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo? |
What Anthony said is correct! You should do
VMM= Xen.gz
Image=uncompressed Linux kernel image <===== Xen can't uncompress image
Initrd=initrd file as usual
-Fred
Xu, Anthony wrote:
> 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
_______________________________________________
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?, Xu, Anthony |
Next by Date: |
RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, takebe_akio |
Previous by Thread: |
RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, Xu, Anthony |
Next by Thread: |
RE: [Xen-ia64-devel] Progress on RHEL4, but blocked at xlilo?, takebe_akio |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|