Requesting some changes for xen PKGBUILD to work with --enable-ovmf

Question

For background about this issue, you may want to read these two E-Mails to edk2 Mailing List:
http://sourceforge.net/p/edk2/mailman/e … sg32776907
http://sourceforge.net/p/edk2/mailman/e … sg32793684
Basically, it goes like this:
- Xen can be compiled with the optional --enable-ovmf option, so it can make DomU VMs using UEFI Firmware. Instructions here:
http://wiki.xen.org/wiki/OVMF
This can be done in Arch Linux by adding in the ./configure line of PKGBUILD --enable-ovmf, adding an additional step where makepkg downloads Source Code from edk2 repository.
- Currently, it fails to build that way with this error:
http://lists.xen.org/archives/html/xen- … 02855.html
This error is caused because the edk2 Source Code that xen pulls during build is fresh and doesn't include any patch to make it aware that Arch Linux has both Python 3 (python) and Python 2 (python2). By default, it tries to compile with Python 3, so it fails.
- Assuming than the Python version issue was fixed (I did it in a non-elegant way, replacing /usr/bin/python with /usr/bin/python2), it will still fail with this error:
https://bugs.archlinux.org/task/40277
https://aur.archlinux.org/packages/ovmf-svn/ (Some of the latest comments)
This error is caused by building with GCC 4.9, earlier versions seems unaffected.
The AUR has also a very similar package (If not identical) that is based on edk2 Source Code, the same which xen downloads while building, ovmf-svn:
https://aur.archlinux.org/packages/ovmf-svn/
This one has a PKGBUILD which includes some lines that seem to point that it is aware of both the python version issue, and the GCC 4.9 build issue, by providing a patch:
https://aur.archlinux.org/packages/ov/ovmf-svn/PKGBUILD
Reelevant lines seems to be these ones:
    msg "Fix GenFw: ERROR 3000: Invalid, Unsupported section alignment"
    patch -Np1 -i "${srcdir}/edk2-basetools-add-gcc4.9-support.patch" || true
    patch -Np1 -i "${srcdir}/edk2-ovmfpkg-add-gcc4.9-support.patch" || true
    msg "Use python2 for UDK BaseTools"
    sed 's|python |python2 |g' -i "${EDK_TOOLS_PATH}/BinWrappers/PosixLike"/* || true
    sed 's|python |python2 |g' -i "${EDK_TOOLS_PATH}/Tests/GNUmakefile"
I didn't found any info regarding if Xen can work with OVMF ready-to-use binaries, or either building ovmf-svn, which I didn't tested but I suppose should build properly. All instructions regarding using Xen with OVMF request that it is added as option during build time. This forces me to have to modify the edk2 Source Code that xen downloads.
Basically, what I want to request is if xen PKGBUILD can be modified to include a statement that checks if --enable-ovmf is being used, then make the appropriate changes to the edk2 Source Code that gets downloaded while building Xen so it successfully builds. This could *POSSIBILY* be based on existing ovmf-svn PKGBUILD code.
This change could also be applied to other xen-based packages that can also be builded with --enable-ovmf and presents the same issues.

Answer 1

FINALLY managed to get this thing working:
http://i.imgur.com/ZWTRcn0.png
I tried to build xen with --with-system-ovmf= as suggested like ten times or so, with no success. While xen seemed to build fine, when I tried to create a UEFI DomU, it simply opens and inmediately closes, through if using SeaBIOS worked fine. On xen IRC there was another Arch Linux user claiming that he recently got Xen with OVMF working using that parameter and the bios.bin binary from the ovmf-bin package from AUR. Installing ovmf-bin then providing xen the full path (--with-system-ovmf=/usr/share/ovmf/bios.bin) didn't worked, neither building ovmf-svn myself then using ovmf_x64.bin (Or renaming it to OVMF.fd, ovmf.bin, etc). It always builded perfectly, yet it failed to make a UEFI DomU. Still, both Firmwares worked when using qemu from the official Arch Linux repository (Note that ovmf-bin bios.bin is 1 MiB in size while ovmf-svn ovmf_x64.bin is 2 MiB, not sure what accounts for the difference).
So how I got it working? A bit complex:
- While in my first post I mention that ovmf-svn had a patch for GCC 4.9, it seems than the patch was removed in the last two days. Without the patch, ovmf-svn still builded properly, so I expected than the GCC 4.9 fix got included in edk2 Source Repository. This was blocking me earlier, so decided to give --enable-ovmf another go.
- Renamed python2 to python as a workaround to not have to touch the edk2 tree that xen downloads, which worked the last time.
- Used makepkg with --enable-ovmf in the PKGBUILD ./configure line. I expected it to work due what I mentioned earlier, but it still fails with the GCC 4.9's GenFw: ERROR 3000.
- As a last resort measure, I decided to try to merge into xen the source that ovmf-svn PKGBUILD modifies, as that one builds properly.
- I replaced all the directories inside xen/src/xen-4.4.1/tools/firmware/ovmf-dir-remote/ with the ones from ovmf-svn/src/tianocore-edk2-svn_build/. Not all directories were replaced, seems than ovmf-svn just downloads the parts of the tree required for building the OVMF Firmware, not everything, which xen does.
- Used makepkg again, which used the existing source to try to build again.
- It builded, no python or GenFw error. Installed the new package, rebooted, tried to make the UEFI DomU and BAM! There it is, as you can see in the Screenshot.
Why can some users get this running with just providing bios.bin from ovmf-bin while I have to do a walk around the globe is anyone guess...
To not derail this request further, I can say the following:
- Assuming than --with-system-ovmf= works consistently, which for me didn't, is currently possible to build Xen with OVMF, so making a more complex PKGBUILD to be able to use --enable-ovmf may not be needed.
- --enable-ovmf is still useful because it may reduce a two-step process (Installing ovmf-bin or building ovmf-svn) into one, through I'm not sure if there are pros/cons for each approach besides than you will have latest OVMF version compared to the ready-to-use binary. It also makes xen package more compatible with the mainstream Xen instructions, as  --with-system-ovmf= is quite unknow.
These decisions are for kantras to make.
Last edited by zir_blazer (2014-09-06 06:54:02)