Xen project Mailing List

There is a regression in both PCI and VGA Passthrough in Xen 4.4.1 when compared to 4.3.2. Due to the added complexity of VGA Passthrough, I was suggested to focus instead in my PCI Passthrough issue, which involves the integrated Sound Card of my Motherboard. While it passes to the DomU and works, it produces robotic, distorted and lagged noise everytime it reproduces sound. The Video Card is an absolute no-go. On the previous Xen version, everything else being equal, both works properly.

I have been trying to gather as much information as possible of my issue according to Xen Wiki articles http://wiki.xen.org/wiki/Debugging_Xen and http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen so this E-Mail comes attached with tons of logs.

HARDWARE
Processor: Intel Xeon E3-1245V3 (Haswell) - http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
Motherboard: Supermicro X10SAT (Chipset C226, BIOS R2.0) - http://www.supermicro.com/products/motherboard/Xeon/C220/X10SAT.cfm
Sound Card: Integrated Realtek ALC1150
Video Card: Haswell IGP, and a Radeon 5770 (Which is the GPU I always pass)

SOFTWARE Dom0
OS: Arch Linux
I did a totally fresh install with October 2014 ISO specifically to test this, in a setup as dull and simple as was possible. The installation process was quite similar, but not identical, to that of the Arch Linux Wiki https://wiki.archlinux.org/index.php/Beginners%27_guide

Boot: BIOS Boot with Syslinux as Boot Loader booting Xen as a GZ Image
On previous setups I tested UEFI Boot (Done with the proper procedure, which was building binutils for x86_64-pep support before building Xen and using the Xen EFI executable to boot), with same results.
In all cases, I use xen-pciback.hide as Kernel parameter to hide the Sound Card PCI Address, in BIOS Boot it is in /boot/syslinux/syslinux.cfg, while for UEFI Boot it is in /boot/xen.cfg

Compiler Flags: -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4
Arch Linux package system (Which I use for building xen packages) uses by default the options of /etc/makepkg.conf, which has those default values for both CFLAGS and CXXFLAGS. MAKEFLAGS is commented out so it uses only one Thread.
On earlier setups I included CFLAGS=-march=native and MAKEFLAGS=-j4 as suggested here https://wiki.archlinux.org/index.php/makepkg but results were the same.

Linux Kernel: Default Arch Linux 3.16 Linux Kernel
For my latest normalized test I only used BIOS Boot with the default Kernel. Earlier, I also used a custom builded 3.17 RC4, which I require for UEFI Boot as that version introduces official UEFI Dom0 support and is the only way that I managed to get working a full Xen UEFI Boot.

Kernel Config: Default config for 3.16 x86_64 Arch Linux, see here: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/config.x86_64?h=packages/linux
When I tested with Linux Kernel 3.17 RC4, as I had to build that one myself, I decided to include in the Kernel all the config options stated in Xen Wiki, here: http://wiki.xenproject.org/wiki/Mainline_Linux_Kernel_Configs#Configuring_the_Kernel_for_dom0_Support
Excepcions are CONFIG_ACPI_PROCFS=y and CONFIG_XEN_PRIVILEGED_GUEST=y, which aren't included in the latest Kernels, and the 3 BACKEND settings, which in that link are mentioned to be included as modules, but I builded them into the Kernel
Also, in some other part of the Xen Wiki its mentioned that in order to do PCI Passthrough using the Xen PCI Back parameter like I do, you need to have CONFIG_XEN_PCIDEV_BACKEND included into the Kernel, not as a module: 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.29
However, I got both PCI and VGA Passthrough properly with the default config that got CONFIG_XEN_PCIDEV_BACKEND as a module, building it into the Kernel didn't seem to have any effect at all. That info seems to be rather dated a they mention Kernel 2.6.32, still, I included that option just to be safe. In any case, results with default 3.16 Kernel and my custom 3.17 RC4 were identical regarding the PCI Passthrough issue.

Xen: Downloaded and builded both xen and xen-4.3 packages from Arch User Repository: https://aur.archlinux.org/packages/xen/ and https://aur.archlinux.org/packages/xen-4.3/
Everything was default. I did not include in either build the ATI Passthrough patch, which is commented by default.
Default PKGBUILD for Xen 4.4.1 includes the --enable-xend option, however, I don't use the xm toolstack, and I recall that in one build I removed it, with same results.

Xen Toolstack: Always xl

Others packages: X.org 1.16, Openbox Window Manager, and Intel GPU Drivers. That's the bare minimum required to be able to get a functional GUI so I can use xl create from a Terminal, a SDL Xen window pop ups so I can see and interact with the DomU.

SOFTWARE DomU
OS: Windows XP SP3
A fresh WXP SP3 install. The ISO I used was heavily modified with nLite by me a few times in the past, however, no component was ever removed or Hotfix applied, just some changes in default config. It worked fine in both native installs and the previous Xen versions.

Drivers: WDM_R274.exe / Realtek ALC1150
R2.74 EXE installer for WXP downloaded from here: http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=14&PFid=24&Level=4&Conn=3&DownTypeID=3&GetDown=false

Everything else is default. Not even GPLPV Drivers installed. The Sound Card was first shown to DomU after the WXP install, by closing the DomU, modifying the DomU config file to add the pci address, then creating it again. Uninstalling Xen 4.4.1 and installing Xen 4.3.2 gets the Sound Card working. In 4.4.1, I tested mainly with Device Model qemu-xen-traditional, however, also tested commeting it out to use default qemu-xen (As I hear that some people had results with even VGA Passthrough with qemu-xen in 4.4.1), with same results.

In total, these are all the setups I had:

December 2013: Xen 4.3.1, BIOS Boot with Syslinux, Arch Linux ISO dated Dec 2013 and whatever Linux Kernel with default config options it had at that time
This was my original setup, which I changed recently. Had one year worth of use with both Sound Card and Video Card passthrough. Worked as intended.

September 2014: Xen 4.3.2, BIOS/UEFI Boot with Syslinux/Gummiboot, Arch Linux ISO dated Oct 2014, Linux Kernel 3.16 with default config options or custom 3.17 RC4
Both Sound Card and Video Card works, including using my previous DomU, in either BIOS mode with either Kernel or UEFI with 3.17. The minimal DomU works as expected with only the Sound Card. The only shortcoming I found running UEFI, is that using "reboot" command in console, sometimes freezes in the last line when it says it is ready to reboot, other times it does work. Seems prone to freeze when I just turned it on and want to reboot, but can reboot consistently on prolonged sessions.

September 2014: Xen 4.4.1, BIOS/UEFI Boot with Syslinux/Gummiboot, Arch Linux ISO dated Oct 2014, Linux Kernel 3.16 with default config options or custom 3.17 RC4
Sound Card passthrough to the minimal DomU (Which I created for testing passthrough in 4.4.1, before I downgraded to 4.3.2 to test again) does not work, robotic noise and interference as described. VGA Passthrough is a total no-go, but I suppose than fixing whatever regression annoys the Sound Card will fix the Video Card too. After tons of testing with different things (BIOS or UEFI, Compiler flags, Kernel version, Kernel config), I conclude that this is broken at least for my setup, as not even once I made it work.

Attached are as much logs as I could muster:

lspci-vvv.txt lspci -vvv output
testwxp.cfg DomU Config file
syslinux-4.3.2.cfg syslinux.cfg file / Xen 4.3.2
syslinux-4.4.1.cfg syslinux.cfg file / Xen 4.4.1
dmesg-4.3.2.txt dmesg output / Xen 4.3.2
dmesg-4.4.1.txt dmesg output / Xen 4.4.1
xl-dmesg-4.3.2.txt xl dmesg output / Xen 4.3.2
xl-dmesg-4.4.1.txt xl dmesg output / Xen 4.4.1
xl-info-4.3.2.txt xl info output / Xen 4.3.2 (Which seems identical to what I saw in /var/log/xen/console/hypervisor.log)
xl-info-4.4.1.txt xl info output / Xen 4.4.1 (Which seems identical to what I saw in /var/log/xen/console/hypervisor.log)
xl-v-create-4.3.2.txt xl -v create testwxp.cfg / Xen 4.3.2 (Had to write this one by hand because using >> for output just included the first line and nothing else, could be wrong)
xl-v-create-4.4.1.txt xl -v create testwxp.cfg / Xen 4.4.1 (Had to write this one by hand because using >> for output just included the first line and nothing else, could be wrong)
xl-wxp-4.3.2.log /var/log/xen file / Xen 4.3.2
xl-wxp-4.4.1.log /var/log/xen file / Xen 4.4.1
qemu-dm-wxp-4.3.2.log /var/log/xen file / Xen 4.3.2
qemu-dm-wxp-4.4.1.log /var/log/xen file / Xen 4.4.1
xen-hotplug.log /var/log/xen file / Not included because was empty

If you need anything else, please ask before I dismantle the test setup and put to work a production Xen 4.3.2. I hope that someone can catch what causes the regression.

[Xen-devel] PCI and VGA Passthrough regressions on Xen 4.4.1 vs 4.3.2