On 11/20/2010 01:28 PM, Kevin O'Connor wrote:
On Sat, Nov 20, 2010 at 01:18:18PM -0500, Stefan Berger wrote:
On 11/20/2010 01:05 PM, Kevin O'Connor wrote:
Is it something like stacks.c:call32() or is it via SMM?
The way it works is that there is a jumptable with entries to the function in the 'high bios'. That jumptable along with all the other 32 bit code gets relocated to upper memory and in the 'lower BIOS' I keep a pointer to the jumptable in the 'high bios' for the upcall code to see. It's basically similar to what I have previously contributed to Bochs BIOS in Xen, just that the upcall code can deal with parameter passed via registers or a limited number on the stack.
http://xenbits.xensource.com/xen-4.0-testing.hg?file/e9156d9d996b/tools/firm...
That looks to be doing the same thing that stacks.c:call32() does.
As it looks, this function allows no parameters to be passed. What I would be adding is a function allowing transitioning from 16 bit to 32 bit with >3 parameters (6 currently). There's some nastiness involved due to the 'ret + n' of functions being called with stack parameters, which starts with 4 parameters, and which does need explicit code in the transitioning function to fix up the stack as the caller expects it. As said, I am using a call table for transitioning that but calls are rather invisible from the C code perspective due to some tricks with #defines.
The assumption that the BIOS would fill up is not given yet, as was the case for Bochs... but it's rather easy now to support the extension into 32 bit space.
Stefan
BTW, are you reserving the relocated code or are you only doing this during the init phase?
The 'high bios' functions should be accessible all the time basically. So, the relocated code needs to be marked as e820-reserved memory -- I suppose that should do the trick then?
Yes, but of course that means the OS can't use the memory then. Why does the code need to be in high memory - why not just have it in the f-segment?
-Kevin