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
now.
-- Keir
> -- Keir
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|