On Sat, Jan 26, 2013 at 3:12 PM, Jordan Justen <jljus...@gmail.com> wrote:
> On Sun, Jan 20, 2013 at 3:42 PM, David Woodhouse <dw...@infradead.org>
> wrote:
> > The main issue I have on the OVMF side is that it locks the entire
> > memory region from 0xC0000-0xFFFFF to be read-only, right before
> > invoking the Legacy16Boot method. This upsets SeaBIOS, which puts a
> > stack in the E0000 segment for use during hardware interrupts and other
> > calls which may otherwise overflow a caller's stack. There isn't
> > anywhere *else* it could put this stack, easily.
>
> Is this still an issue? If so, why not use EBDA?
>
Unfortunately, the EBDA isn't sufficient for all of SeaBIOS'
low-memory allocation requirements. SeaBIOS requires the ability to
allocate ram that wont move (for DMA buffers, PCI v3 permanent low-mem
allocations, etc.). The EBDA can unfortunately be relocated by
optionroms and by some old DOS programs.
It's technically possible to allocate ram (that wont be relocated)
from the end of the 9-segment (by messing with the "memory size"
variable in the BDA) and SeaBIOS used to do this. However, that
mechanism has other problems - it's complex to implement, some really
old DOS programs don't respect the "mem size" variable, and it
conflicts with some option roms that attempt to manually allocate ram
there. So, SeaBIOS now uses just the e-segment for its low-memory
needs.
I'm a bit surprised that OVMF would mark all of the 0xc0000-0xfffff
area as read-only. There are lots of old programs that want to use
parts of that area as memory.
-Kevin
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
