WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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