On Mon, Jul 25, 2016 at 02:42:11PM +0200, Zoran Stojsavljevic wrote:
[...] *Probably some module required for your baremetal fedora is missing in initramfs. First of all, remove "quiet" option to receive more details. If that's about missing module, you can regenerate initramfs:
The system boots fine under coreboot+seabios, so I'm fairly certain it isn't an initrd problem. There are no modules at all in the kernel that I've embedded as the coreboot payload. Even without quiet there is no output after the "kexec_core: Starting new kernel" message.
I did find this note from 2008 that mentioned a similar issue regarding xen, kexec and coreboot:
http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/
# The no-real-mode option stops Xen from doing some bios # calls, and it also tells it to ignore the e820 bios table. # Note that you need to pass no-real-mode as the first xen # command line argument, otherwise it won’t work. # # And somehow that solves the problem for Xen 3.1.3 and 3.1.4, # both under qemu + coreboot and qemu + bochs. Kexec’ing into # Xen 3.1.2 triple-faults qemu under qemu + coreboot, but # works fine under qemu + bochs. That smells like a coreboot # bug. I’ll try on real hardware tomorrow to see if this bug # is specific to our qemu port, or a more general coreboot # problem. To be continued..
"no-real-mode" does not affect my results on real hardware. I'm still seeing what looks like a triple fault, leading to coreboot being restarted. At least it gets back to the prompt in less than a second...
On Mon, Jul 25, 2016 at 01:27:22PM -0600, Trammell Hudson wrote:
I did find this note from 2008 that mentioned a similar issue regarding xen, kexec and coreboot:
http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/
Following the links to the xen-devel mailing list had some hints:
# There seems to be a regression with regard to kexec'ing into # a Xen kernel between Xen 3.1.0 (confirmed working) and 3.1.3 # (confirmed not working). I would try 3.1.1 and 3.1.2 but # source for 3.1 versions older than 3.1.3 no longer seems to # be available for download. I still had source for 3.1.0 # lying around, luckily.
I decided to try Xen 3.1.0 and found that the hypervisor does start up just fine when kexec'ed from my Linux payload launched from Coreboot (although my 4.6 payload isn't compatible with the ELF loader used by the older Xen):
https://www.flickr.com/photos/osr/27931937284/in/photostream/lightbox/
Ward's further testing was the Xen 3.2 tree would fail to kexec even with the "no-real-mode" flag and came to the conclusion that:
# This is likely a coreboot bug, so I'll have to track that # down. Any information about differences between what 3.2.1 # and 3.1.4 require to be kexec'ed into would be most helpful # though.
Unfortunately there weren't any followups.
On Mon, Jul 25, 2016 at 03:56:22PM -0600, Trammell Hudson wrote:
# There seems to be a regression with regard to kexec'ing into # a Xen kernel between Xen 3.1.0 (confirmed working) and 3.1.3 # (confirmed not working).
I was able to reproduce this in qemu, which allowed me to debug it much faster. The problem is that 3.1.3 is making BIOS calls to try to initialize the VGA console in xen/arch/x86/boot/video.S, while 3.1.0 had much of it hard coded in the xen/drivers/video/vga.c file.
I nop'ed out the calls to do the real mode stuff in trampoline_boot_cpu_entry, which avoids lots of things like:
# Set the 80x25 mode. If already set, do nothing. set_80x25: movw $0x5019, bootsym(force_size) # Override possibly broken BIOS use_80x25: movw $0x1202, %ax # Force 400 scan lines movb $0x30, %bl int $0x10 movw $0x0003, %ax # Mode 3 int $0x10 stc ret
I also replaced vga.c with the one from the 3.1.0 Xen tree to hardcode the text mode 3 configuration. Now it is able to kexec the Xen 3.1.3 kernel from my Coreboot+Linux payload with no BIOS.
Unfortunately 3.1.3 is ancient; I'm going to build the more modern Xen 4.6.x to see if I can repeat these fixes to boot into Qubes.
On Tue, Jul 26, 2016 at 09:37:20AM -0600, Trammell Hudson wrote:
[...] Unfortunately 3.1.3 is ancient; I'm going to build the more modern Xen 4.6.x to see if I can repeat these fixes to boot into Qubes.
This required a few more hacks, but it works now. The problem is not with Coreboot, but with Xen assuming that there is a BIOS it can call to setup the video display and also assuming that there is an EBDA that contains pointers to various structures.
My 4.6.3 Xen tree is hacked up right now with stuff copied from old versions of the tree, so I'll clean it up and see if they are interested in accepting patches.
On Tue, Jul 26, 2016 at 12:09:18PM -0600, Trammell Hudson wrote:
On Tue, Jul 26, 2016 at 09:37:20AM -0600, Trammell Hudson wrote:
[...] Unfortunately 3.1.3 is ancient; I'm going to build the more modern Xen 4.6.x to see if I can repeat these fixes to boot into Qubes.
This required a few more hacks, but it works now. The problem is not with Coreboot, but with Xen assuming that there is a BIOS it can call to setup the video display and also assuming that there is an EBDA that contains pointers to various structures.
My 4.6.3 Xen tree is hacked up right now with stuff copied from old versions of the tree, so I'll clean it up and see if they are interested in accepting patches.
Oh, wow, thank you! Sorry that I didn't spend time tracking that down properly back in 2008. I'd be interested to know if Xen takes the patch.
Thanks, Ward.
On Tue, Jul 26, 2016 at 02:48:42PM -0400, Ward Vandewege wrote:
Oh, wow, thank you! Sorry that I didn't spend time tracking that down properly back in 2008. I'd be interested to know if Xen takes the patch.
Thank *you* for isolating it to the change between 3.1.0 and 3.1.3 so many years ago. Without that hint it would have been a much longer process to figure out what was wrong.
-
Trammell Hudson -
Ward Vandewege