[Fedora-xen] Xen, Linux and EFI.

[Fedora-xen] Xen, Linux and EFI.

[Konrad Rzeszutek Wilk]

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:
   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:
   http://lists.xen.org/archives/html/xen-devel/2012-02/msg02027.html
  
   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
   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 mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen

Re: Xen, Linux and EFI.

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 2966 bytes --]

On Wed, Jul 11, 2012 at 4:45 PM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> 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:
>    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:
>    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.

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
>    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
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 4164 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

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@oracle.com> 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@lists.xen.org
>      [6]http://lists.xen.org/xen-devel
> 
> References
> 
>    Visible links
>    1. mailto:konrad.wilk@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-devel@lists.xen.org
>    6. http://lists.xen.org/xen-devel

> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen

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

[Konrad Rzeszutek Wilk]

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.wilk@oracle.com> 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:
> >    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:
> >    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 think the later only. Thought I am not sure how in the first case (GRUB2)
how the E820 is made to be passed to the hypervisor kernel.

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

Huh. E801 is from the ancient days. I am a bit surprised that grub2.efi would
manufacture such ancient map.

So just to make sure I am not confused - you ran GRUB2 and ran with the
normal hypervisor and Linux kernel. What did you serial output look like?


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

What does the memory map look like when you booted with GRUB2.efi + Linux.
Was the memory map the same or different? I am trying to figure out if
the issue is that Xen needs extra code to deal with a GRUB2 manufactured
E801 map - and that the baremetal kernel already has such logic.

> 
> So I ended up booting with a SLES kernel. Not even sure if opensuse 12.1
> will work.

With what hypervisor? Same one you used when you tried GRUB2 with Xen earlier?
> 
> 
>    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
> >    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
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
--
xen mailing list
xen@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/xen

Re: Xen, Linux and EFI.

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 4057 bytes --]

On Thu, Jul 12, 2012 at 9:31 AM, Konrad Rzeszutek Wilk <
konrad.wilk@oracle.com> wrote:

> >
> > 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
>
> Huh. E801 is from the ancient days. I am a bit surprised that grub2.efi
> would
> manufacture such ancient map.
>
> So just to make sure I am not confused - you ran GRUB2 and ran with the
> normal hypervisor and Linux kernel. What did you serial output look like?
>
>
Yes.
I dont have the serial output now. I wiped out the server and installed
SLES 11 SP2 on it. :(


> >  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.
>
> What does the memory map look like when you booted with GRUB2.efi + Linux.
>

Sorry. I dont have that info now, since I uninstalled ubuntu from it.



> Was the memory map the same or different? I am trying to figure out if
> the issue is that Xen needs extra code to deal with a GRUB2 manufactured
> E801 map - and that the baremetal kernel already has such logic.
>
>
I do have the memory map when I forced xen to follow the multiboot-e820
logic.
I posted about this issue on xen-users.
http://lists.xen.org/archives/html/xen-users/2012-07/msg00034.html

The hack (patch) is available in the above post. The e820 map that xen saw
was
(XEN) Multiboot-e820 RAM map:
(XEN)  0000000000000000 - 000000000006c000 (usable)
(XEN)  000000000006c000 - 000000000006d000 (ACPI NVS)
(XEN)  000000000006d000 - 000000000009f000 (usable)
(XEN)  000000000009f000 - 00000000000a0000 (ACPI NVS)
(XEN)  0000000000100000 - 000000007c11d000 (usable)
(XEN)  000000007c11d000 - 000000007ec92000 (reserved)
(XEN)  000000007ec92000 - 000000007f7bf000 (ACPI NVS)
(XEN)  000000007f7bf000 - 000000007f7ff000 (ACPI data)
(XEN)  000000007f7ff000 - 000000007f800000 (usable)
(XEN)  0000000080000000 - 0000000090000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000001080000000 (usable)
(XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126]

The machine booted. But xen saw only one CPU out of 16.

FYI, I checked the memory map that xen sees now (xen 4.1.2 sles11sp2
version)
and its the same. Except the ACPI errors arent there. xen recognizes all 16
cpus.



> >
> > So I ended up booting with a SLES kernel. Not even sure if opensuse 12.1
> > will work.
>
> With what hypervisor? Same one you used when you tried GRUB2 with Xen
> earlier?
> >
>

As stated above. SLES11 SP2. The hypervisor is the one that comes packaged
in
the distro xen 4.1.2_14-0.5.5 and the sles11 kernel 3.0.13-0.27-xen


>
> >    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
> > >    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
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> > >
>
>

[-- Attachment #1.2: Type: text/html, Size: 5988 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: Xen, Linux and EFI.

[Daniel Kiper]

On Wed, Jul 11, 2012 at 04:45:05PM -0400, Konrad Rzeszutek Wilk 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:
>    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:
>    http://lists.xen.org/archives/html/xen-devel/2012-02/msg02027.html
>
>    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
>    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 :-(

Hmmm... It looks quite interesting. Could I get involved in EFI stuff?

Daniel

Re: Xen, Linux and EFI.

[Konrad Rzeszutek Wilk]

On Thu, Jul 12, 2012 at 11:39:51AM -0400, Shriram Rajagopalan wrote:
> On Thu, Jul 12, 2012 at 9:31 AM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com> wrote:
> 
> > >
> > > 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
> >
> > Huh. E801 is from the ancient days. I am a bit surprised that grub2.efi
> > would
> > manufacture such ancient map.
> >
> > So just to make sure I am not confused - you ran GRUB2 and ran with the
> > normal hypervisor and Linux kernel. What did you serial output look like?
> >
> >
> Yes.
> I dont have the serial output now. I wiped out the server and installed
> SLES 11 SP2 on it. :(
> 
> 
> > >  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.
> >
> > What does the memory map look like when you booted with GRUB2.efi + Linux.
> >
> 
> Sorry. I dont have that info now, since I uninstalled ubuntu from it.
> 
> 
> 
> > Was the memory map the same or different? I am trying to figure out if
> > the issue is that Xen needs extra code to deal with a GRUB2 manufactured
> > E801 map - and that the baremetal kernel already has such logic.
> >
> >
> I do have the memory map when I forced xen to follow the multiboot-e820
> logic.
> I posted about this issue on xen-users.
> http://lists.xen.org/archives/html/xen-users/2012-07/msg00034.html
> 
> The hack (patch) is available in the above post. The e820 map that xen saw
> was
> (XEN) Multiboot-e820 RAM map:
> (XEN)  0000000000000000 - 000000000006c000 (usable)
> (XEN)  000000000006c000 - 000000000006d000 (ACPI NVS)
> (XEN)  000000000006d000 - 000000000009f000 (usable)
> (XEN)  000000000009f000 - 00000000000a0000 (ACPI NVS)
> (XEN)  0000000000100000 - 000000007c11d000 (usable)
> (XEN)  000000007c11d000 - 000000007ec92000 (reserved)
> (XEN)  000000007ec92000 - 000000007f7bf000 (ACPI NVS)
> (XEN)  000000007f7bf000 - 000000007f7ff000 (ACPI data)
> (XEN)  000000007f7ff000 - 000000007f800000 (usable)
> (XEN)  0000000080000000 - 0000000090000000 (reserved)
> (XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
> (XEN)  00000000ff800000 - 0000000100000000 (reserved)
> (XEN)  0000000100000000 - 0000001080000000 (usable)
> (XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126]
> 
> The machine booted. But xen saw only one CPU out of 16.
> 
> FYI, I checked the memory map that xen sees now (xen 4.1.2 sles11sp2
> version)
> and its the same. Except the ACPI errors arent there. xen recognizes all 16
> cpus.

Oh, it might be that SLES version of hypervisor has the patches
to deal with EFI, while the one in Ubuntu (or Fedora) does not!

If you were to boot Ubuntu with a SLES hypervisor (yeah, lets
go wild here), it might have worked - at least booted. The
toolstack would probably be very confused.

> 
> 
> 
> > >
> > > So I ended up booting with a SLES kernel. Not even sure if opensuse 12.1
> > > will work.
> >
> > With what hypervisor? Same one you used when you tried GRUB2 with Xen
> > earlier?
> > >
> >
> 
> As stated above. SLES11 SP2. The hypervisor is the one that comes packaged
> in
> the distro xen 4.1.2_14-0.5.5 and the sles11 kernel 3.0.13-0.27-xen

Right, so Jan (SuSE) has been busy working on EFI so I bet he back-ported
the EFI patches in Xen 4.1. They might not be in Ubuntu Xen 4.1 :-(

Thought they probably are in the Xen-unstable.

Re: Xen, Linux and EFI.

[Jan Beulich]

>>> On 11.07.12 at 23:27, Shriram Rajagopalan <rshriram@cs.ubc.ca> wrote:
> So I presume that the dom0 kernel EFI support needs to be done for both
> cases (grub2.efi and xen.efi) ?

Even if you found they're unneeded for the grub2 case, you'd
end up with a system that would only work as long as all the
legacy bits and pieces are still provided by the platform. Once
you want to run on a truly EFI-only system, there's no way
around having the Dom0 pieces in place.

Plus, for the grub2 case you also have to add code to actually
retrieve the information you need to access EFI runtime
services (e.g. to get your UP-only problem resolved that you
mentioned in another response).

> So I ended up booting with a SLES kernel. Not even sure if opensuse 12.1
> will work.

It will, as will (obviously) 12.2.

Jan