Re: [coreboot] kexec of Xen hypervisor from a Linux payload

[Trammell Hudson]

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

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

[Ward Vandewege]

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.

-- 
Ward Vandewege
GPG Key: 25F774AB

Do you use free software? Donate to join the FSF and support freedom at
 http://www.fsf.org/register_form?referrer=859

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

[Trammell Hudson]

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.

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

[Trammell Hudson]

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.

-- 
Trammell
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

[Trammell Hudson]

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.

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

[Trammell Hudson]

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...

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] kexec of Xen hypervisor from a Linux payload

[Zoran Stojsavljevic]

Hello Trammell,

Reading what you are trying. Have no idea what Qubes OS is... I apologize
for my ignorance, but I am (fortunately) willing to learn. New OSes, new
tricks, and this old dog (me) is still willing to learn new tricks (in
other words, also learning experience for me)?! ;-)

So, since you are coming to dracut after all, I am suspecting that
something with your initramfs is not quite right... It often happens to me
with Linux distros I am using for HW/SoC testing (95% Fedora distro).

In order to determine what is really wrong with your setup, I asked my best
friend for dozens of years: www.google.com, searching for pattern ->
*initramfs*-4.1.13-9.pvops.qubes.x86_64.img


The following appeared:
https://groups.google.com/forum/#!msg/qubes-users/DYw6f2LpDA8/z4fDsy9CBwAJ

*And this cot my eye (from Marek Marczykowski-Górecki):*






*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: 0.
Make sure you've copied modules from
Qubes (/lib/modules/4.1.13-9.pvops.qubes.x86_64) 1. Call "dracut -f
/initramfs-4.1.13-9.pvops.qubes.x86_64.img 4.1.13-9.pvops.qubes.x86_64 *

Could help (you might search other options with the provided search
pattern) ... :-)

Please, let us know.

Zoran

On Mon, Jul 25, 2016 at 6:05 AM, Trammell Hudson  wrote:

> I've successfully built a 4.6.4 Linux kernel payload for CoreBoot and
> flashed it onto the top 4 MB of the boot ROM on my Thinkpad x230.
> The runtime is a dynamic linked busybox with glibc, as well as a copy
> of the kexec binary from my Ubuntu laptop.
>
> kexec of a xen kernel (multiboot-x86) results in an immediate reboot
> into the coreboot payload:
>
> https://www.flickr.com/photos/osr/27913702804/lightbox
>
> kexec of a Linux kernel produces the expected result (panic in this
> case since I didn't pass any additional parameters to find a root fs):
>
> https://www.flickr.com/photos/osr/27914585663/lightbox
>
> This might be a xen problem (triple fault leading to reset vector?)
> rather than a coreboot issue, however the same Xen hypervisor config
> works with grub2 on the drive loaded by seabios payload.
>
> There is this old document that describes a "--vmm" option to kexec,
> but that doesn't seem to exist in the current kexec tree:
>
> https://xenbits.xen.org/docs/4.3-testing/misc/kexec_and_kdump.txt
>
> --
> Trammell
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] kexec of Xen hypervisor from a Linux payload

[Trammell Hudson]

I've successfully built a 4.6.4 Linux kernel payload for CoreBoot and
flashed it onto the top 4 MB of the boot ROM on my Thinkpad x230.
The runtime is a dynamic linked busybox with glibc, as well as a copy
of the kexec binary from my Ubuntu laptop.

kexec of a xen kernel (multiboot-x86) results in an immediate reboot
into the coreboot payload:

https://www.flickr.com/photos/osr/27913702804/lightbox

kexec of a Linux kernel produces the expected result (panic in this
case since I didn't pass any additional parameters to find a root fs):

https://www.flickr.com/photos/osr/27914585663/lightbox

This might be a xen problem (triple fault leading to reset vector?)
rather than a coreboot issue, however the same Xen hypervisor config
works with grub2 on the drive loaded by seabios payload.

There is this old document that describes a "--vmm" option to kexec,
but that doesn't seem to exist in the current kexec tree:

https://xenbits.xen.org/docs/4.3-testing/misc/kexec_and_kdump.txt

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot