Problems arises when supporting EFI + GRUB2 + Xen with Multiboot2 boot specification

Previously I wrote a post to discuss the limitations for Multiboot boot specification, today I saw that XEN hypervisor also has the similar problems. 

See these two links below, Daniel Kiper (from Oracle) have some proposals to solve XEN/Multiboot2 issue on EFI/Grub2 platforms.
http://lists.xen.org/archives/html/xen-devel/2014-05/msg02928.html
https://lists.gnu.org/archive/html/grub-devel/2014-06/msg00016.html
http://www.slideshare.net/xen_com_mgr/xen-in-efiworld20140801finaldk

To summarize it, the problems are:

• Grub2 calls ExitBootServices() before jumpping to the entry point of XEN, which means all the EFI Boot Services will be terminated then.
• Multiboot2 specification doesn't define 64-bit entry point and its initial transition state, which means that even both XEN and Grub2/EFI are running in 64bit environment, during handover stage Grub2 must have to switch processor mode to 32bit, and XEN must also have a stub that switches processor mode back to normal 64-bit. 
• XEN requires some information from Grub2, e.g. EFI tables/Functions, ACPI, Memory map, VGA, EDD data, etc. Hence, some extra Multiboot2 TAGs must be introduced to support passing on those informations. But this also requires changes upstreamed to Grub2.

Previously, in our own proprietary VMM, we worked around this issue to boot guest Linux OS with "noefi" flag in vmlinuz cmdline options (see this link for Linux parameters). We did it in the same way with tboot project, because we just get EFI System Descriptor Table from Grub2, and then boot Linux guest OS as usually like on a legacy platform (e.g. with legacy e820 memory map format). However, XEN should NOT do it in this way.