Previously I had Xen 4.3.1 with Arch Linux using I-don't-recall what Linux Kernel (Should be dated Dec 2013), with Syslinux as BIOS Boot Loader. I had two devices being passed to a WXP SP3 DomU, a Radeon 5770, and the integrated Realtek Sound Card of my Supermicro X10SAT Motherboard. Toolstack was xl, and I was using Device Model qemu-xen-traditional. This setup worked for the last 9 months quite flawless.
Due to the fact that I wanted to re-think my storage (Used plain files for VM storage instead of LVM volumes, IO performance was painful in scenarios with tons of small files), I also decided that it was a great oportunity to do a fresh Arch Linux install, so that's what I did.
My target was getting from Xen two features: Xen UEFI boot, that last year I couldn't, and integrating OVMF so I can create UEFI DomUs, on top of what I already got. Anyways, starting with a fresh UEFI install of the latest Arch Linux ISO, I also installed Xorg and Openbox, so it was a very minimalist Dom0. For compiling, I decided to change a few settings to go from march=x86_64 to native and get the most out of my Haswell. After building binutils with x86_64-pep support and xen, I installed xen, put the xen.efi file on /boot, modified Gummiboot UEFI Boot Manager, and tried to boot.Nothing, a black screen like last year.
This time I had an ace under the sleeve: I was aware that Linux Kernel 3.17 included official UEFI Dom0 support. So I downloaded the latest Kernel 3.17 RC5 from Arch User Repositories, builded, installed, changed xen.cfg to use it, and voila, finally Xen UEFI booting is working for me. That's good. I also tried UEFI DomU with OVMF, that also worked. What didn't worked, however, was launching my previous main WXP SP3 DomU, it BSODed on boot. Removing the devices being passed maded it booteable. After some experimentation, I figured out that VGA Passthrough wasn't the only thing not working: If I only passed the Sound Card, while it "works", it has distorted, robotic sound, making it painful to the ears. To confirm that, I also created a new DomU and did a fresh install of WXP SP3 and installed only the Realtek Drivers, and it also failed. Because the Sound Card PCI Passthrough was always much easier than VGA Passthrough, I decided to focus on fixing that one.
So I started to try solutions. First of all, because Xen documentation claims that in order to use xen-pciback.hide as option for Xen, you need to have it build into the Kernel:
http://wiki.xen.org/wiki/Xen_PCI_Passthrough#Static_assignment_for_built-in_xen-pciback_.28when_xen-pciback_is_compiled_into_the_kernel_and_NOT_loaded_as_a_module.29I checked Arch Linux Kernel default options, and it is loaded only as a module:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/config.x86_64?h=packages/linuxHowever, that also should apply to my one year old Kernel, and I used xen-pciback.hide there too, but with good results.
As
I was going to do my first custom Kernel, I also decided to include into the Kernel all these options (Except two that got removed from Kernel a few versions ago):http://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs#Configuring_the_Kernel_for_dom0_SupportBuilded, installed, tried again. Same results.
Then I tried to use Syslinux and the Xen 4.4.1 GZ image for BIOS instead of UEFI with the EFI executable, with the older Kernel 3.16. Still the same.
Finally, I decided to fall back to Xen 4.3.2. Builded with the x86_64-pep binutils, OVMF support, and the ATI Passthrough patch, and also rebuilded a vanilla Linux Kernel 3.17 RC5 (I can't get Xen to work with UEFI boot with anything else). Guess what, now both Sound and GPU works, again, and while doing UEFI boot. What doesn't work is OVMF - if I create a DomU with bios = "ovmf", it opens then inmediately closes. But well, at least I got a new feature that I was obsessed with during months, Dom0 UEFI boot.
While some people has recently reported success, for me, Xen 4.4.1 was a total regression in the PCI/VGA Passthrough arena. Would like to know if anyone knows what could be the cause. I find more important the Sound Card than the Video Card one, and I think that fixing whatever makes the Sound Card go awkward should possibily fix the Video Card, too.
