qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [Bochs-developers] [PATCH v2 5/6] Don't use unreservedm


From: Sebastian Herbszt
Subject: [Qemu-devel] Re: [Bochs-developers] [PATCH v2 5/6] Don't use unreservedmemory inBIOS.
Date: Mon, 10 Nov 2008 20:55:51 +0100

Kevin O'Connor wrote:
On Sun, Nov 09, 2008 at 06:40:18PM +0100, Sebastian Herbszt wrote:
Kevin O'Connor wrote:
> Random note - I'm told that some option roms can relocate the EBDA.
> Setting the stack in the EBDA area will prevent that from working.

The option rom for the LSI SCSI controller (8xx_64.rom) relocates the
EBDA. It moves it from 0x9fc0 to 0x9f00.

Thanks Sebastian.

Do you know of any document or specification that details how the bios
is supposed to handle this case and/or how an option rom should
accomplish this?

Unfortunatelly not. I discovered this behaviour while playing with the
mentioned option rom.

One of the questions I have, is how the bios should handle the e820
map when this happens.  Currently, bochs bios always reserves 1K at
0x9fc0.  If the ebda is moved to 0x9f00, should bochs reserve 1K at
0x9f00 or 4K at 0x9f00?

Same problem with the simpler INT 12h interface. Currently it returns
the value in 0040h:0013h. This is the static value BASE_MEM_IN_K
which is 640 - EBDA_SIZE. EBDA_SIZE is the BIOS EBDA size.
Guess the value at 0040h:0013h has to be recalculated after option rom
scan based on the EBDA length field. The BIOS set's this to EBDA_SIZE
and if an option rom does relocate and resize it it should update that field.

So far the map reported by e820 does match INT 12h (both report 0x9fc0).
With this patch e820 reports 0x9f00 and INT 12h sticks to 0x9fc0. I am not
sure about the implications tho.

- Sebastian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]