On Fri, 2014-01-10 at 12:49 -0500, Kevin O'Connor wrote:
On Fri, Dec 06, 2013 at 11:56:22AM +0000, David
We expect to use the space between the top of
option ROMs and the bottom
of our own BIOS code as a stack. OVMF was previously marking the whole
region from 0xC0000 to 0xFFFFF read-only before invoking our Legacy16Boot
method. Read-only stack considered harmful.
Version 0.98 of the CSM spec adds the UmaAddress and UmaSize fields, which
allow the CSM to specify a memory region that needs to be writable.
There exists CONFIG_MALLOC_UPPERMEMORY which we could turn off to use
the 9-segment, but that isn't particularly useful for the CSM case
either because that memory isn't ours to play with until the final
Legacy16Boot call. There's a LowPmmMemory given to use by UEFI to play
with, but that's right in the *middle* of low memory and using that for
persistent allocations would be painful. So just require
CONFIG_MALLOC_UPPERMEMORY when building a CSM.
Are you still looking at this? If I recall correctly, you were going
to run a test without CONFIG_MALLOC_UPPERMEMORY set.
Apologies for the sporadic nature of my attention to this. It's back at
the top of my pile again for a while. I've submitted the corresponding
patch to EDK2 and it should hopefully be accepted now that the spec is
As I'm testing on Quark today, I tried reverting the EDK2-side patch and
the SeaBIOS patch, and disabling CONFIG_MALLOC_UPPERMEMORY. It booted
FreeDOS and worked fine.
Then I re-enabled CONFIG_MALLOC_UPPERMEMORY and it still worked, which
wasn't expected :)
I'll have to retest with OVMF under Qemu (with KVM).