On Mon, Aug 23, 2010 at 08:37:16AM +0300, Avi Kivity wrote:
On 08/23/2010 01:57 AM, Kevin O'Connor wrote:
On Sun, Aug 22, 2010 at 09:18:43PM +0300, Avi Kivity wrote:
On 08/22/2010 08:40 PM, Kevin O'Connor wrote:
On Sun, Aug 22, 2010 at 08:07:53PM +0300, Avi Kivity wrote:
I see that ld has some support for overlays, perhaps we can use that?
The overlay support is basically just another way of manipulating the run-time addresses of the code at build time. Unfortunately, it can only specify static addresses, and I don't think there is any safe static address that can be used (outside of 0xc0000-0xfffff).
Is that not useful? We can push, say the IDE and virtio drivers to overlay the same address range in the e/f segments, and have the stubs pull them in as necessary.
I guess you're describing a way of swapping parts of the BIOS in. It could be made to work, but seems very complicated.
That's what overlay is, it used to be a hot method way back. Why do you think it's complicated? There's some support for it in ld.
It is not hot method any more for a reason though :) It is complicated because you need to decide at build time what can overlay with what.
Relocating the code isn't that bad. It should just be a matter of storing which parts of the code rely on a fixed address, and then updating those addresses at runtime. Something like:
// Info provided by build extern u32 Relocs[]; extern u32 NumRelocs; extern void *OrigCodeAddr; extern u32 CodeSize; // Relocation code. memcpy(newaddr, OrigCodeAddr, CodeSize); for (i=0; i<NumRelocs; i++) *(u32*)(newaddr + Relocs[i]) += (newaddr - OrigCodeAddr);If the code can be relocated, it should be okay to put it at the top of high memory. Relocating should be more transparent than "swapping" to developers, as it wouldn't impose any limits on what can code can call other code.
Overlays are transparent too, you typically have stubs for overlaid code which call the overlay manager to swap the code in if necessary. These stubs are generated automatically.
Relocation should work as well, and indeed has less constraints, but needs more build support.
-- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
-- Gleb.