Re: [Xen-devel] Coreboot + Linux + kexec + Xen

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/08/2016 19:54, Trammell Hudson wrote:
> This is in reply to an ancient post to the xen-devel list:
>
> http://ward.vandewege.net/blog/2008/08/kexecing-into-a-xen-kernel/
> http://old-list-archives.xenproject.org/archives/html/xen-devel/2008-08/msg00298.html
>
> Ward Vandewege wrote (in 2008):
>
>> 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'm building a similar configuration to Ward's setup, although with a more
> modern version of Xen.  My laptop has Coreboot with a Linux payload as a
> bootloader flashed into the ROM, which then validates and invokes Qubes'
> Xen 4.6 hypervisor with kexec().  It worked as long as I had a BIOS image
> in ROM, such as SeaBIOS, but not when I used Linux as the bootloader,
> even with "no-real-mode" as a parameter on the Xen command line.

Just to get things straight, it functions with SeaBIOS in place, but
fails with you skip the BIOS entirely?

You say "with Linux as the bootloader".  Does this mean you are booting
Linux as a Coreboot payload, then using kexec() to get into Xen?

>
> Keir Fraser replied to Ward's follow up question:
>
>>> Is there a significant difference between booting 3.1.4 and
>>> 3.2.1 with kexec in terms of BIOS requirements?
>> If you specify no-real-mode in both cases then there
>> should be no difference.  If Xen does not drop back into
>> real mode then it cannot make use of any legacy BIOS
>> services.
> After some tracing, I determined that this is not enitrely accurate and
> likely the cause of Ward's failure to boot 3.2.1 on real hardware.
> Xen assumes that there is an Extended BIOS Data Area (EBDA), which is
> not the case for the Linux-as-bootloader configuration.  The parameters
> have not been parsed at this time in the boot code, so it always trusts
> that it can find this structure.

This sounds like a bug which could definitely be fixed, although we will
need some alternative way of identify where it is safe to locate the
16bit trampoline in low memory.

I suppose we can probably make better use of the multiboot-provided
memory map, even in the early ASM.  That would avoid relying exclusively
on the EBDA.

>
> Patching xen/arch/x86/boot/head.S to set trampoline_phys to point to
> the end of MB_mem_lower (as it was done in 3.1.0) and also passing in
> "no-real-mode" allows 4.6.3 to boot on the Coreboot system with Linux
> payload.

That is good to hear.  We should probably do that.

>
> However, it would then fault in the VGA configuration since at that same
> time the xen/drivers/video/vga.c was changed from "directly poking the
> registers to enter video mode 3" to doing it the right way by asking
> the VESA BIOS to configure the video card.  Since my system has no
> VGA BIOS (Coreboot does native VGA init on the x230 and Qemu), this leads
> to faults when Xen attempts to invoke BIOS calls.  Forward porting the
> ten year old vga.c file from 3.1.0 allowed 4.6.3 to work perfectly.

Again, this is clearly a bug which should be fixed.

> Since this is the only mention I've seen of this setup since 2008,
> I understand that merging this patch into the Xen kernel might not be
> the highest priority.  But for time travellers looking to boot
> Coreboot + Linux payload + kexec + Xen + Qubes on their Thinkpads,
> these patches might prove to be useful.

Going forwards, there are a number of usecases for booting Xen in
non-legacy environments which have been proposed, and all would benefit
from improvements such as these.

Are you in a position to submit patches?  If so, they would be very welcome.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel