Arch Linux User Repository

@zir_blazer: Ok, was finally able to get the OVMF tree, which is pulled via git during compile, to compile. This new update should have this, along with some more cleanup as well as enabling spice support. Also, if binutils has been rebuilt with the correct option, it will detect the xen.efi file and will move it into /boot. An example xen.cfg is also included as /etc/xen/efi-xen.cfg - simply copy it over into /boot/xen.cfg and edit it with your options.

@zir_blazer: This is on my todo list (Last night I was actually going over the forum posts you had made previously) however I've not had a lot of spare time recently to sit down and work on this (as well as enabling spice support) I'm about to do a major overhaul on my primary desktop system (which uses the xen hypervisor) so was going to tackle that at the same time. I've also been watching your posts on xen-users and xen-devel, so am aware of it; i've not personally experienced those issues however my setup is a little different so wouldn't likely be hit by some of that (i.e I use a usb headset to my domU, rather than pass through sound)

I would like to repeat my request for OVMF support, which allows to make DomUs with UEFI Firmware instead of BIOS. The idea is that by adding --enable-ovmf in the ./configure line, it automatically downloads 200 MiB or so from edk2 Source Repository and builds it to get a binary that is included with Xen, so you can later create a DomU with it: http://wiki.xen.org/wiki/OVMF While I didn't tried building with OVMF recently, the last time I attemped to do so, it fails to build cause the Source Code it downloads from edk2 repository isn't modified to build properly in Arch Linux (It isn't aware that python = Python 3.x and it has to use python2 instead, and it also had some issues with GCC 4.9). The other option for doing so, --with-system-ovmf=<ovmf.bin path> never worked for me either. The only success I had was when I merged the modified Source Code from the ovmf-svn package into the directory where xen downloads the edk2 source. Also, I repeated that procedure with the xen-4.3 package but I wasn't able to get OVMF working. Nor I tested with 4.4.1 to check if it still works. In other news, while toying around with Xen 4.4.1 I hit some nasty regressions in PCI and VGA Passthrough. The Sound Card works but produces tons of noise everytime that it reproduces a sound (Workaroundeable), and VGA Passthrough is a total no-go. Both things works fine if I try with the xen-4.3 package. Would like to know if anyone else that tested both 4.3.x and 4.4.1 had issues with Passthrough. More info here: http://lists.xen.org/archives/html/xen-devel/2014-10/msg00549.html Would like to know if other Passthrough users had issues or not between those two versions.

I hereby confirm that the Xen package on my server has upgraded successfully by my regular updating method using yaourt, from v4.4.0 to v4.4.1. Just a hint for other users, don't forget to update grub manually afterwards; this can save you a phone call to your service provider. (Whoooops) :D Thanks Kantras for analyzing and fixing.

Thanks to a log provided by ArthurBorsboom, I've been able to work out why some people were having build issues and the fix is applied in the new version I've just uploaded. As always, the change log should show all that has happen per new upload

@kantras I am able to install now. I'm unsure what I did differently this time around (even checked my past bash history). I think I was having mirror issue a couple weeks back. Thanks for your help.

I'm aware of it and will be uploading a new version once I've completed build-testing

This looks like a serious vulnerability that has just emerged: http://xenbits.xen.org/xsa/advisory-108.html https://xen-orchestra.com/blog/xen-security-and-xsa-108/

@kantras I have no problems building it in a clean chroot: https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot. I am on a 64-bit system and have the multilib repository enabled and only have the base-devel package installed in the chroot.

Update: I still haven't been able to reproduce the compile issue that some of you are reporting. I've created a VM, installed Arch with only a base set of packages (base + base-devel), installed the default dependancies for the xen build, and ran makepkg to build the package; worked as expected. I'm going to roll back to the snapshot I made after the first booting of the VM, and will try some other things to see if I can recreate the issue