I am a little confused. in RHEL5.7 xen version , in /boot/ ,there are some files about xen: .vmlinuz-2.6.18-268.el5xen.hmac config-2.6.18-268.el5xen vmlinuz-2.6.18-268.el5xen xen.gz-2.6.18-268.el5 System.map-2.6.18-268.el5xen symvers-2.6.18-268.el5xen.gz xen-syms-2.6.18-268.el5 two important files：xen-syms-2.6.18-268.e15 and xen.gz-2.6.18-268.e15 a) I unzip xen.gz-2.6.18-268.e15 to get xen-2.6.18-268.e15 I know in grub.conf , we will use this file (xen.gz link to this file) ## readelf -h xen-2.6.18-268.e15 ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 //why ELF32 ,it should be ELF64 Data: 2''s complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x100000 //as document , xen-kernel will be load physically address 0x100000 Start of program headers: 52 (bytes into file) Start of section headers: 980552 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 1 Size of section headers: 40 (bytes) Number of section headers: 3 Section header string table index: 2 b)## readelf -h xen-syms-2.6.18-268.el5 ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 // this is ELF64 .above is ELF32 Data: 2''s complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0xffff828c80100000 //why here is virtual address , and above 0x100000 is physical address ? Start of program headers: 64 (bytes into file) Start of section headers: 984784 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 1 Size of section headers: 64 (bytes) Number of section headers: 22 Section header string table index: 21 --------------------------------- my question is that , what is xen-syms-2.6.18-268.el5(readelf result is virtual address) used for ? it seems that useless. grub.conf seems don''t need it. in xen/arch/x86/boot/head.S: #undef bootsym_phys #define sym_phys(sym) ((sym) - __XEN_VIRT_START I know all symbols address should be virtual address , its physical address should be minus __XEN_VIRT_START if want to check symbols , ## objdump -t xen-syms-2.6.18-268.el5 xen-syms-2.6.18-268.el5: file format elf64-x86-64 SYMBOL TABLE: no symbols thanks very much for your comments! -Bob Zhang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, 2011-08-19 at 08:27 +0100, Lin-Bao Zhang wrote:> my question is that , what is xen-syms-2.6.18-268.el5(readelf result > is virtual address) used for ? it seems that useless. grub.conf > seems don''t need it.The -syms file is purely for debuggers (e.g. to run tools like gdb on) because it contains full debug symbols etc it is never loaded by the boot loader or anything like that. The actual hypervisor binary (which is stripped, i.e. has no symbols) is encapsulated in a 32 bit ELF file for compatibility with the multiboot standard, which does not handle 64 bit ELF files. See xen/arch/x86/boot/mkelf32.c and the Makefile runs which use it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
thanks very much!
another question:
in xen-4.1.0: code about trampoline.S
1， in head.S:
-------------------------------------------------------------------------------------
/* Copy bootstrap trampoline to low memory, below 1MB. */
mov $sym_phys(trampoline_start),%esi
mov $bootsym_phys(trampoline_start),%edi
mov $trampoline_end - trampoline_start,%ecx
rep movsb
//bob comment, I know its function :copy beginning address(esi) ''s ecx
bytes to edi address.
mov $bootsym_phys(early_stack),%esp
call cmdline_parse_early
/* Jump into the relocated trampoline. */
jmp $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry)
a)where defines early_stack ?
I just see:
early_stack:
(the last line in file ,no content again)
b) what is function of ” mov $bootsym_phys(early_stack),%esp" ?
is this related with trampoline relocation ?
c)how to make sure these trampoline code can''t overlap other area for
example EBDA(directly below 0xa0000) ?
d) jmp $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry)
as my idea , should jump to BOOT_TRAMPOLINE ,but why jump to
trampoline_boot_cpu_entry ? what is relationship between
trampoline_boot_cpu_entry and BOOT_TRAMPOLINE ?
2, about reloc.S
#include "cmdline.S"
reloc:
#include "reloc.S"
.align 16
.globl trampoline_start, trampoline_end
trampoline_start:
#include "trampoline.S"
trampoline_end:
-------------------------------------------------------------------------------------------
why I can''t find reloc.S in my xen-4.1.0 code ?
thanks very much! maybe my questions are too many , thanks again!
-Bob Zhang
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Fri, 2011-08-19 at 09:59 +0100, Lin-Bao Zhang wrote:> why I can''t find reloc.S in my xen-4.1.0 code ?xen/arch/x86/boot/Makefile builds it from reloc.c Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 19/08/2011 09:59, "Lin-Bao Zhang" <2004.zhang@gmail.com> wrote:> thanks very much! > another question: > > in xen-4.1.0: code about trampoline.S > 1， in head.S: > ------------------------------------------------------------------------------ > ------- > /* Copy bootstrap trampoline to low memory, below 1MB. */ > mov $sym_phys(trampoline_start),%esi > mov $bootsym_phys(trampoline_start),%edi > mov $trampoline_end - trampoline_start,%ecx > rep movsb > //bob comment, I know its function :copy beginning address(esi) ''s ecx > bytes to edi address. > > mov $bootsym_phys(early_stack),%esp > call cmdline_parse_early > > /* Jump into the relocated trampoline. */ > jmp $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry) > > a)where defines early_stack ? > I just see: > early_stack: > (the last line in file ,no content again)Stacks grow downwards/backwards in memory. The early_stack definition is immediately *before* the early_stack label.> b) what is function of ” mov $bootsym_phys(early_stack),%esp" ? > is this related with trampoline relocation ?The trampoline stack (early_stack) is now allocated within the trampoline code/data area, rather than being hard-coded at an address (e.g., 0x98000).> c)how to make sure these trampoline code can''t overlap other area for > example EBDA(directly below 0xa0000) ?Move it lower. In 4.1 you can see we moved the trampoline down to 0x7c000. It fits entirely below 0x80000, so it cannot overlap within even the theoretically largest possible 128kB EBDA.> d) jmp $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry) > as my idea , should jump to BOOT_TRAMPOLINE ,but why jump to > trampoline_boot_cpu_entry ? what is relationship between > trampoline_boot_cpu_entry and BOOT_TRAMPOLINE ?trampoline_boot_cpu_entry is not at the start of the trampoline area, hence jumping at BOOT_TRAMPOLINE would not work. We instead jump at BOOT_TRAMPOLINE + (trampoline_boot_cpu_entry-trampoline_start). Handily that is exactly what bootsym_phys() macro calculates for us. -- Keir> > 2, about reloc.S > > #include "cmdline.S" > > reloc: > #include "reloc.S" > > .align 16 > .globl trampoline_start, trampoline_end > trampoline_start: > #include "trampoline.S" > trampoline_end: > ------------------------------------------------------------------------------ > ------------- > why I can''t find reloc.S in my xen-4.1.0 code ? > > thanks very much! maybe my questions are too many , thanks again! > > -Bob Zhang > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
2011/8/19 Keir Fraser <keir@xen.org>:> On 19/08/2011 09:59, "Lin-Bao Zhang" <2004.zhang@gmail.com> wrote: > >> thanks very much! >> another question: >> >> in xen-4.1.0: code about trampoline.S >> 1， in head.S: >> ------------------------------------------------------------------------------ >> ------- >> /* Copy bootstrap trampoline to low memory, below 1MB. */ >> mov $sym_phys(trampoline_start),%esi >> mov $bootsym_phys(trampoline_start),%edi >> mov $trampoline_end - trampoline_start,%ecx >> rep movsb >> //bob comment, I know its function :copy beginning address(esi) ''s ecx >> bytes to edi address. >> >> mov $bootsym_phys(early_stack),%esp >> call cmdline_parse_early >> >> /* Jump into the relocated trampoline. */ >> jmp $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry) >> >> a)where defines early_stack ? >> I just see: >> early_stack: >> (the last line in file ,no content again) > > Stacks grow downwards/backwards in memory. The early_stack definition is > immediately *before* the early_stack label. >yes , yes , I just saw symbols ,early_stack address should be same as trampoline_end .>> b) what is function of " mov $bootsym_phys(early_stack),%esp" ? >> is this related with trampoline relocation ? > > The trampoline stack (early_stack) is now allocated within the trampoline > code/data area, rather than being hard-coded at an address (e.g., 0x98000). >>> c)how to make sure these trampoline code can''t overlap other area for >> example EBDA(directly below 0xa0000) ? > > Move it lower. In 4.1 you can see we moved the trampoline down to 0x7c000. > It fits entirely below 0x80000, so it cannot overlap within even the > theoretically largest possible 128kB EBDA. >exactly , it seems that trampoline code is basicly 10K , so 0x7c000 should be lower enough ,it can''t overlap to 0x80000, this will be very rich I finally understand why you tell me to use 0x80000. (0xa0000 - 128K EBDA max size) .>> d) jmp $BOOT_CS32,$bootsym_phys(trampoline_boot_cpu_entry) >> as my idea , should jump to BOOT_TRAMPOLINE ,but why jump to >> trampoline_boot_cpu_entry ? what is relationship between >> trampoline_boot_cpu_entry and BOOT_TRAMPOLINE ? > > trampoline_boot_cpu_entry is not at the start of the trampoline area, hence > jumping at BOOT_TRAMPOLINE would not work. We instead jump at > BOOT_TRAMPOLINE + (trampoline_boot_cpu_entry-trampoline_start). Handily that > is exactly what bootsym_phys() macro calculates for us. > > -- Keir >thanks Keir very very much! , it is so nice of you. I quite appreciate your help on this issue. I learned a lot from you! thanks again! --Bob Zhang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Stacks grow downwards/backwards in memory. The early_stack definition is > immediately *before* the early_stack label. > >> b) what is function of ” mov $bootsym_phys(early_stack),%esp" ? >> is this related with trampoline relocation ? > > The trampoline stack (early_stack) is now allocated within the trampoline > code/data area, rather than being hard-coded at an address (e.g., 0x98000). >a) the Stack ,how to grow downwards ? if device changed/added,the stack will grows much ? what device or function code will use this stack ? what time does this stack grow ? Can this stack overwrite other things when grow downwards ? in xen-4.1.0 , this stack top equals to trampoline_end ,will it overwrite trampoline_code ? I think maybe impossible ,because trampoline code has been moved to BOOT_TRAMPOLINE . why do I have such question ,please see my b) b) it seems that the core problem is the "early_stack" , in my case , Stack top is overlap P410i EBDA area when stack grows downwards,so system can''t boot again. but But there is another question puzzled : If 0x98000 value is wrong , we will think in any case , system will be corrupted ,but if we disable or unplug FC card , system will boot normally. Very mystery. Following is my guess: I guess : 0x95400 ~ <------ 0x98000 (stack top) ~ 0xa0000 0x95400 … P410i_EBDA_start ….. P410i_EBDA_end …. 0x98000 We know stacks grow downwards/backwards in memory , so I guess P410i EBDA area should be located in sub-area in 0x95400 ~0x98000. I feel the stack size will change as device number. Maybe ,if we plug FC card , the stack should be more larger , occasionally reach P410i EBDA area. If unplug FC card , the stack will be so small that it can’t reach P410i EBDA . who knows , maybe only P410i firmware guys and FC card firmware guys , because only they know their EBDA area range. I will consult our firmware guys to verify my idea. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel