Re: [Fedora-xen] [Xen-devel] Xen, Linux and EFI.

[Pasi Kärkkäinen]

On Wed, Jul 11, 2012 at 05:27:08PM -0400, Shriram Rajagopalan wrote:
>     On Wed, Jul 11, 2012 at 4:45 PM, Konrad Rzeszutek Wilk
>     <[1]konrad.wilk(a)oracle.com&gt; wrote:
>  
>       Hey,
>  
>       There has been some discussion about EFI and SecureBoot and such.
>  
>       Most of the time I get questions in the form of "How do I get Fedora 17
>       with Xen to do EFI", I am going to concentrate on Fedora, but I think
>       this applies to other distros too.
>  
>       From my reading (I hadn't actually tried EFI yet), there are two ways
>       to bootup a system:
>  
>        - Using grub2.efi. Grub2 does the EFI API calls and calls the Xen
>       hypervisor
>          as if there were no EFI. This means no need for the EFI calls from
>          Linux or Xen are required).
>  
>        - Using xen.efi. Xen can be built as a PE (Portable Executable) and it
>       can
>          boot as an EFI image. Naturally you also need to provide a
>       configuration
>          file and here are the details on it:
>          [2]http://xenbits.xen.org/docs/unstable/misc/efi.html
>  
>          And you would also need to configure the EFI nvram to execute xen.efi
>          instead of grub2.efi.
>  
>          For the Linux side, the kernel needs to make new EFI variant
>       hypercalls.
>          Currently the SLES kernel is capable of it. The upstream Linux kernel
>          cannot do it. There were patches proposed for it:
>          [3]http://lists.xen.org/archives/html/xen-devel/2012-02/msg02027.html
>  
>     Does the Linux side dom0 kernel changes need to be done irrespective of
>     the
>     two options above ? or does it apply only for booting with xen.efi ?
>     I spent a week trying to get Xen boot with grub2.efi (ubuntu 12.04).
>     I ended up getting "Not enough memory to relocate domain 0".
>     So I presume that the dom0 kernel EFI support needs to be done for both
>     cases (grub2.efi and xen.efi) ?
>     Additional info:
>      Hardware: IBM System X server.
>      It appeared that when booting xen under grub2.efi, xen was picking up a
>     e-801 map
>      instead of the e-820 map that was on the system. I forced xen code to a
>     multiboot
>      e-820 map instead of the native one ( based on a forum post I saw).
>      That didnt help much.
>  
There have been also other reports about this EFI e801 issue here on xen-devel ..

-- Pasi


>     So I ended up booting with a SLES kernel. Not even sure if
> opensuse 12.1
>     will work.
>  
>          which were mostly ports of how SLES did it (And they should reflect
>          the proper ownership, which they don't have right now).
>  
>          The EFI maintainer (Matthew) commented
>          [4]http://lists.xen.org/archives/html/xen-devel/2012-02/msg00815.html
>          that he would like a better abstraction model for it. Mainly to
>          push those calls deeper down (so introduce the registration in the
>          the efi_calls). Or perhaps by providing in
>       boot_params.efi_info.efi_systab
>          a finely crafted structure pointing to Linux functions that would
>          do the hypercalls.
>  
>       And there you have it. In other words it needs somebody willing to
>       look at the patches as a baseline and do some exciting new work.
>       I sadly don't have right now the time to address this :-(
>  
>       _______________________________________________
>       Xen-devel mailing list
>       [5]Xen-devel(a)lists.xen.org
>       [6]http://lists.xen.org/xen-devel
>  
>  References
>  
>     Visible links
>     1. mailto:[e-mail]
>     2. http://xenbits.xen.org/docs/unstable/misc/efi.html
>     3. http://lists.xen.org/archives/html/xen-devel/2012-02/msg02027.html
>     4. http://lists.xen.org/archives/html/xen-devel/2012-02/msg00815.html
>     5. mailto:[e-mail]
>     6. http://lists.xen.org/xen-devel 
>  _______________________________________________
>  Xen-devel mailing list
>  Xen-devel(a)lists.xen.org
>  http://lists.xen.org/xen-devel