define BOOT_TRAMPOLINE and stack based on result of probing EBDA area by INT12

define BOOT_TRAMPOLINE and stack based on result of probing EBDA area by INT12

[Lin-bao Zhang]

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

Re: define BOOT_TRAMPOLINE and stack based on result of probing EBDA area by INT12

[Keir Fraser]

On 31/08/2011 09:47, "Lin-bao Zhang" <zhang.linbao@yahoo.com> wrote:

> 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.

If you actually tried to implement it you'd realise you're stuck. Because
you start off in protected mode and can't make the BIOS call, until you are
in real mode, which requires the trampoline to be set up.

 -- Keir

Re: define BOOT_TRAMPOLINE and stack based on result of probing EBDA area by INT12

[Lin-bao Zhang]

>>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.

I want to say "I am not familiar with assembler code", sorry ,I have lost "not". 
so ,this is my idea. if I am wrong , thanks for your correction. I am newbie for xen-hypervisor indeed, I am still reading its code and implementation.  I think this will be a good entry point for newbies to know xen-hypervisor.

RE: Re: define BOOT_TRAMPOLINE and stack based on result of probing EBDA area by INT12

[djmagee]

I haven't looked at any of the relevant code, so forgive me if there's some obvious reason this wouldn't work, but shouldn't the 'mem_lower' field in the multiboot data structure tell us the upper bound for that first 640KB of memory?  That would avoid needing a real-mode BIOS call to determine a safe location for the stack.

-----Original Message-----
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Keir Fraser
Sent: Wednesday, August 31, 2011 4:55 AM
To: Lin-bao Zhang; xen-devel@lists.xensource.com
Subject: [Xen-devel] Re: define BOOT_TRAMPOLINE and stack based on result of probing EBDA area by INT12

On 31/08/2011 09:47, "Lin-bao Zhang" <zhang.linbao@yahoo.com> wrote:

> 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.

If you actually tried to implement it you'd realise you're stuck. Because
you start off in protected mode and can't make the BIOS call, until you are
in real mode, which requires the trampoline to be set up.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Re: define BOOT_TRAMPOLINE and stack based on result of probing EBDA area by INT12

[Alan Cox]

On Wed, 31 Aug 2011 09:55:10 +0100
Keir Fraser <keir@xen.org> wrote:

> On 31/08/2011 09:47, "Lin-bao Zhang" <zhang.linbao@yahoo.com> wrote:
> 
> > 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.
> 
> If you actually tried to implement it you'd realise you're stuck.

Re-read the original. The EBDA is accessible at BIOS segment offset 0E.
You don't need to make a BIOS call to read it, just load the location and
check it against 0.W in which case one isn't present.

At that point you know where to put your bits.

Obviously once you get into the world of EFI and the like there are
different ways all this should occur, but for good old BIOS stuff it
works fine.

Re: Re: define BOOT_TRAMPOLINE and stack based on result of probing EBDA area by INT12

[Keir Fraser]

On 31/08/2011 20:25, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote:

> On Wed, 31 Aug 2011 09:55:10 +0100
> Keir Fraser <keir@xen.org> wrote:
> 
>> On 31/08/2011 09:47, "Lin-bao Zhang" <zhang.linbao@yahoo.com> wrote:
>> 
>>> 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.
>> 
>> If you actually tried to implement it you'd realise you're stuck.
> 
> Re-read the original. The EBDA is accessible at BIOS segment offset 0E.
> You don't need to make a BIOS call to read it, just load the location and
> check it against 0.W in which case one isn't present.
> 
> At that point you know where to put your bits.
> 
> Obviously once you get into the world of EFI and the like there are
> different ways all this should occur, but for good old BIOS stuff it
> works fine.

Ah, makes sense. And our real-mode code is now relocatable, which was
implemented as part of support for EFI. That could be used to dynamically
relocate below EBDA for legacy BIOS too.

 -- Keir

Re: Re: define BOOT_TRAMPOLINE and stack based on result of probing EBDA area by INT12

[Keir Fraser]

On 31/08/2011 20:57, "Keir Fraser" <keir.xen@gmail.com> wrote:

> On 31/08/2011 20:25, "Alan Cox" <alan@lxorguk.ukuu.org.uk> wrote:
> 
>> On Wed, 31 Aug 2011 09:55:10 +0100
>> Keir Fraser <keir@xen.org> wrote:
>> 
>>> On 31/08/2011 09:47, "Lin-bao Zhang" <zhang.linbao@yahoo.com> wrote:
>>> 
>>>> 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.
>>> 
>>> If you actually tried to implement it you'd realise you're stuck.
>> 
>> Re-read the original. The EBDA is accessible at BIOS segment offset 0E.
>> You don't need to make a BIOS call to read it, just load the location and
>> check it against 0.W in which case one isn't present.
>> 
>> At that point you know where to put your bits.
>> 
>> Obviously once you get into the world of EFI and the like there are
>> different ways all this should occur, but for good old BIOS stuff it
>> works fine.
> 
> Ah, makes sense. And our real-mode code is now relocatable, which was
> implemented as part of support for EFI. That could be used to dynamically
> relocate below EBDA for legacy BIOS too.

That said the original bug was in a very old version of Xen, and we have
since statically moved our real-mode code below 0x80000 which is apparently
below even the largest possible EBDA. So arguably we should leave it alone
now.

 -- Keir

>  -- Keir
> 
>