Hi Keir ,
we have discussed how to avoid to overlap with EBDA area in subject "xen-kernel
and EDD".
at last, in RHEL5.7s ,we define BOOT_TRAMPOLINE 0x7c000 ,and
- mov $0x98000,%esp
+ mov $(BOOT_TRAMPOLINE + 0x4000),%esp
but some days passed, I finally feel that this modification is somewhat the
best choice for avoid EBDA overwritten.
For EBDA , I have been always discussing with our BIOS colleagues,BIOS guys'
suggestion is like this:
To guarantee to never run into this problem again, the e820 memory map must be
parsed to find a valid memory range before using it. Not the easiest
thing to do in assembly code without a stack, which is why the early loader
folks took the easy route and hardcoded the stack. On most platforms that
works, but to guarantee it works on all, the e820 map must be parsed, and
reserved areas must not be corrupted by the OS.in fact, our xen-hypervisor has
parsed e820 map successfully, but why we don't make use of e820 map result to
judge EBDA bottom ?
from BIOS-provided physical RAM map: BIOS-e820: 0000000000010000 -
0000000000090400 (usable) BIOS-e820: 0000000000090400 - 0000000000a0000
(reserved)We have known that EBDA area is 90400 ~ 0xa0000 . when programming,
EBDA area is certainly different on different BIOS .we can determine the size
of the EBDA by using BIOS function INT 12h, or (often) by examining the word at
0x40E in the BDA .Both of those methods will tell you the location of the
bottom of the
EBDA. http://wiki.osdev.org/Memory_Map_(x86)#.22Low.22_memory_.28.3C_1_MiB.29
1,define a variable named "EBDA_bottom".
2, get EBDA_bottom by above method.
3, stack should equals EBDA_bottom (or EBDA_bottom -1 safely)
4, mov $(EBDA_bottom -1),%esp
in most case , EBDA area is 1K,but we define 0x7c000(this is absolutely
safe),but we will waste too much memory space.
I did test, it can work .Certainly, I am familiar with assembler code, I just
hard code to test:mov 0x903ff , %esp thanks for your corrections , I have
not read over all histories and stories about them, if I am wrong , I am sorry
first.
thanks very much!
-Bob
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|