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

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Mon, 2016-08-08 at 18:54 +0000, Trammell Hudson wrote:
> 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.
> 
> 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.

This appears to be true for the general case of kexec into Xen from
Linux (or from Xen, once I get round to dealing with the separate
issues that exist there).

However...
> 
> diff --recursive -u 
> /home/hudson/build/clean/xen-4.6.3/xen/arch/x86/boot/head.S 
> ./xen/arch/x86/boot/head.S
> --- /home/hudson/build/clean/xen-4.6.3/xen/arch/x86/boot/head.S       
> 2016-06-20 08:08:22.000000000 -0400
> +++ ./xen/arch/x86/boot/head.S        2016-08-03 17:56:37.511121443 -0400
> @@ -86,6 +86,8 @@
>          cmp     $MULTIBOOT_BOOTLOADER_MAGIC,%eax
>          jne     not_multiboot
>  
> +#if 0
> +
>          /* Set up trampoline segment 64k below EBDA */
>          movzwl  0x40e,%eax          /* EBDA segment */
>          cmp     $0xa000,%eax        /* sanity check (high) */
> @@ -108,6 +110,12 @@
>          shl     $10-4,%edx
>          cmp     %eax,%edx           /* compare with BDA value */
>          cmovb   %edx,%eax           /* and use the smaller */
> +#else
> +     // coreboot does not provide an Extended BIOS Data Area pointer
> +     // just stash things the Multiboot structure, adjusted to bytes
> +        mov     MB_mem_lower(%ebx),%eax
> +        shl     $10-4,%eax
> +#endif
>  
>  2:      /* Reserve 64kb for the trampoline */
>          sub     $0x1000,%eax


That much is overkill if the page has just been zeroed. This (along
with "no-real-mode") suffices to get Xen booting for me:

--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -541,6 +541,8 @@ trampoline_bios_setup:
         cmp     $0x100,%edx         /* is the multiboot value too small? */
         jb      2f                  /* if so, do not use it */
         shl     $10-4,%edx
+        or      %ecx,%ecx           /* Don't use the BDA value if it's zero */
+        cmovz   %edx, %ecx
         cmp     %ecx,%edx           /* compare with BDA value */
         cmovb   %edx,%ecx           /* and use the smaller */

Not sure if we can trust that it's always actually zero, though. Before
I contrive other options like checking it for sanity as we do for the
multiboot value, or actually checking (from asm) the command line for
no-real-mode and avoiding the BDA completely.... what *is* the reason
we don't trust the multiboot data? Did bootloaders really lie to us?

If I'm about to update kexec to support multiboot2 anyway, because I
want the relocation support (and I note Xen's MB2 image doesn't provide
a non-UEFI entry point, so I'll need to work on that too)... perhaps it
makes sense to trust the information we get from MB2 and never look at
the BDA in *that* case?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel