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
> <konrad.w...@oracle.com> wrote:
> 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
> 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
> boot as an EFI image. Naturally you also need to provide a
> file and here are the details on it:
> 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
> Currently the SLES kernel is capable of it. The upstream Linux kernel
> cannot do it. There were patches proposed for it:
> Does the Linux side dom0 kernel changes need to be done irrespective of
> 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
> 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
> 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
> 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
> 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
> Visible links
> 1. mailto:konrad.w...@oracle.com
> 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:xen-de...@lists.xen.org
> 6. http://lists.xen.org/xen-devel
> Xen-devel mailing list
xen mailing list