[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: define BOOT_TRAMPOLINE and stack based on result of probing EBDA area by INT12

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

> On 31/08/2011 20:25, "Alan Cox" <alan@xxxxxxxxxxxxxxxxxxx> wrote:
>> On Wed, 31 Aug 2011 09:55:10 +0100
>> Keir Fraser <keir@xxxxxxx> wrote:
>>> On 31/08/2011 09:47, "Lin-bao Zhang" <zhang.linbao@xxxxxxxxx> 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

 -- Keir

>  -- Keir

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.