Arch Linux User Repository

Firstly, thanks for all the work keeping the xen package up to date. I just got it set up and working and it's working great! I thought I'd share this, in case anyone else is interested in booting a grub2 (which is what arch ships with) on a guest VM: https://blog.xenproject.org/2015/01/07/using-grub-2-as-a-bootloader-for-xen-pv-guests/ I haven't done it yet, but it seems .... reasonably straight forward.

Hi Kantras, I found another way to customize the Xen bootloader. You need to edit the /etc/xen/grub.conf file, as described in the Grub section here. https://wiki.archlinux.org/index.php/xen No need to research any further.

That sounds good to me. Thanks!

Hi ArthurBorsboom, The short version is that it never has supported using those options in /etc/default/grub, even before I took maintainership of it; the rewrite I did was keeping with existing functionality, just extending it to also support the lts kernels. I'm actually working on the PKGBUILD for 4.5 now, so I'll add a task to myself to look into 09_xen vs 20_linux_xen (which is the script which comes packaged with grub that uses that variable) and decide which way is best to go to ensure existing configurations aren't broken by any changes I make either.

Hi Kantras, While trying to set a fixed amount of memory for Dom0, I noticed that the 09_xen file of grub, does not pick up the "GRUB_CMDLINE_XEN_DEFAULT" variable in /etc/default/grub, as I believe it should be. See also: http://wiki.xen.org/wiki/Xen_Project_Best_Practices When I manually modify the "XEN_HYPERVISOR_CMDLINE" variable in 09_xen, it does work. However when 09_xen gets updated, this change will be lost. Do you know why the GRUB_CMDLINE_XEN_DEFAULT is not being used by 09_xen?

With xen 4.5 arriving soon, I'm planning to do the same as I did with the 4.3->4.4 transition; the current xen package will be renamed to 'xen-4.4' and 'xen' will be for the 4.5 release. My goal is to keep the last last three revisions in sync with the upstream releases (so 4.3, 4.4 and 4.5).

@zir_blazer: Actually xen maintain their own fork of the OVMF source code, and its from that repository that the build system pulls. This is why I made the comment that I did about the method we use; I didn't want to try against a system install of OVMF as I wasn't sure if all the xen specific patches had been upstreamed and this technically should already be known to be working with xen. I actually tried booting up a live cd via OVMF and it worked great. @ArthurBorsboom: There shouldn't be any impact to existing installs - all that has been done is enabling some support code, that won't be used unless a user enables the specific configuration options (for example, OVMF is a replacement for SeaBIOS, but won't be used unless you add "bios='ovmf'" into the configuration file for the domU. )

What is the impact of these changes on existing Xen installations?

Just tested the new package yesterday, with good results. Using makepkg with the default PKGBUILD automatically downloads OVMF, builds it successfully, and after installing, it is ready to use as I could create an UEFI DomU showing TianoCore splash screen. Amazing work. I think that you're the first one to introduce OVMF support into a Xen package. I do expect that being default build option, some users may have fun trying to make a UEFI DomU for Windows 7/8 or Linux when they notice that support for OVMF is already included and ready to use. But there are some drawbacks. First, that maybe not everyone likes the 200 MiB download. It goes unnoticed when you have 20-30 mins compile time through, so seems minor. The other drawback is that because you're also downloading code from another repository, if for some reason something breaks on the OVMF side, the package will fail to build. Its potentially more work when that happens (Last time was with GCC 4.9 release). A more safe way could be by including a compiled OVMF Firmware in the package and invoking it with --with-system-ovmf=<path>, through I never managed to get it working that way. For as long as everything works, the current way rocks as you get the latest code. I didn't tested Xen UEFI Boot using binutils with x86_64-pep. However, I did recently a feature request for that to be included in default binutils: https://bugs.archlinux.org/task/42540 The sad part of all this is that I'm stuck with Xen 4.3 due to my regression issue, because as I use Xen for a gaming Windows VM, passthrough is a must. So besides testing to say that it works, I will not be able to enjoy it.

I've just modified the 09_xen to add grub support to intel_ucode package. My version of 09_xen automatic detects the presence of /boot/intel-ucode.img and add it to grub.cfg. http://downloads.rhyeworld.it/files/static/isiachi/09_xen