Hi,
It looks like it is but I just thought I should check, is starting SeaBIOS via the ELF entry point (post32 in romlayout.S) rather than via the 16 bit reset vector valid from the SeaBIOS point of view?
I'm considering it as an option for supporting SeaBIOS inside a Xen HVM (AKA fully virtualised) guest. Currently Xen loads "hvmloader" as the initial code to run within the guest. hvmloader does some initial setup, copies the BIOS (previously ROMBIOS but there is now very early support for SeaBIOS too) into the right place and then trampolines to the 16 bit entry point. However almost all of the initial setup is (or at least seems like it will end up being once I've checked it all out) ROMBIOS specific so I am considering the option of just loading SeaBIOS directly in place of hvmloader.
Cheers, Ian.
On Tue, May 10, 2011 at 01:47:34PM +0100, Ian Campbell wrote:
Hi,
It looks like it is but I just thought I should check, is starting SeaBIOS via the ELF entry point (post32 in romlayout.S) rather than via the 16 bit reset vector valid from the SeaBIOS point of view?
It is valid - all coreboot users enter via the post32 stub.
I'm considering it as an option for supporting SeaBIOS inside a Xen HVM (AKA fully virtualised) guest. Currently Xen loads "hvmloader" as the initial code to run within the guest. hvmloader does some initial setup, copies the BIOS (previously ROMBIOS but there is now very early support for SeaBIOS too) into the right place and then trampolines to the 16 bit entry point. However almost all of the initial setup is (or at least seems like it will end up being once I've checked it all out) ROMBIOS specific so I am considering the option of just loading SeaBIOS directly in place of hvmloader.
That's interesting. Some questions - how will Xen obtain the address of post32 - will it use the bios.bin.elf file? On CPU reset / S3 resume (if supported at all), will Xen also call post32 or do a regular real-mode entry?
-Kevin
On Wed, 2011-05-11 at 00:36 +0100, Kevin O'Connor wrote:
On Tue, May 10, 2011 at 01:47:34PM +0100, Ian Campbell wrote:
Hi,
It looks like it is but I just thought I should check, is starting SeaBIOS via the ELF entry point (post32 in romlayout.S) rather than via the 16 bit reset vector valid from the SeaBIOS point of view?
It is valid - all coreboot users enter via the post32 stub.
I suspected as much, thanks for confirming.
I'm considering it as an option for supporting SeaBIOS inside a Xen HVM (AKA fully virtualised) guest. Currently Xen loads "hvmloader" as the initial code to run within the guest. hvmloader does some initial setup, copies the BIOS (previously ROMBIOS but there is now very early support for SeaBIOS too) into the right place and then trampolines to the 16 bit entry point. However almost all of the initial setup is (or at least seems like it will end up being once I've checked it all out) ROMBIOS specific so I am considering the option of just loading SeaBIOS directly in place of hvmloader.
That's interesting. Some questions - how will Xen obtain the address of post32 - will it use the bios.bin.elf file?
Correct, the HVM domain builder takes an ELF file and populates the initial memory image with it and sets up the entry point from there (actually by populating address 0x000000 with a suitable jump but in principal that could be a setvcpucontext hypercall).
On CPU reset / S3 resume (if supported at all), will Xen also call post32 or do a regular real-mode entry?
Xen doesn't really support S3 resume (suspend is supported via PV means), it simply pauses the domain so resume picks up exactly where it left off.
triple faults cause a reboot event, which the toolstack reacts to in a configurable way, usually by rebuilding and starting the domain from scratch, so it'll use the ELF entry point like on first boot. I didn't check other CPU reset mechanisms but I'd expect them to behave similarly.
Ian.
-
Ian Campbell -
Ian Campbell -
Kevin O'Connor