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

[Zir Blazer <zir_blazer@xxxxxxxxxxx>]

>> HARDWARE
>> Processor: Intel Xeon E3-1245V3 (Haswell) - 
>> http://ark.intel.com/products/75462/Intel-Xeon-Processor-E3-1245-v3-8M-Cache-3_40-GHz
>
> I seem to see 8 CPUs while your serial output say it has 4?
>
> Did you disable hyper-threading?

Yes, Hyper Threading is disabled.



> Anyhow, could you when booting under Xen 4.3 (and Xen 4.4) also use
> iommu=verbose,debug

Will try adding that to syslinux.cfg the next time I experiment with that 
install, which should be sooner than later. Is there any specific log file I 
should save, or better to repeat all them? Any other command line I could 
include in case you want to get logs of everything in one go? Also, should I 
get logs with the DomU running, or after closing it?



> And there were no BIOS updates in between using Xen 4.3 or Xen 4.4? I recall 
> that BIOS v1.0 on those
> boards would spit errors.

When I purchased the Motherboard, if I recall correctly, there were no BIOS 
updates posted at Supermicro website, so I should have had the first shipping 
BIOS. There was a BIOS update around the same time I received it (Don't recall 
version because I didn't upgrade, could be 1.1), then another one which is the 
2.0 I have currently, installed from X10SAT4_421.zip which should be from April 
21 2014. So Xen 4.3.1 was installed and used with BIOS 1.0 with no issues for 9 
months or so.

I did update the BIOS two weeks ago while trying UEFI Boot with Xen 4.4.1, due 
to the fact that pretty much all people I saw but me managed to get it working, 
so I through that a Firmware upgrade could fix it. It didn't. I finally got it 
working when I tested with the 3.17 Kernel. Right after that I found the 
Passthrough regression. After giving up seeing that no option could make it 
work, I decided to test again with my older Xen 4.3.1 install and it worked 
fine as always, so that's when I decided to test Xen 4.3.2, and it worked, too. 
So Xen 4.3.1 was tested -briefly- with BIOS 2.0, while 4.4.1 and 4.3.2 
exclusively with 2.0. And some days ago I did an standarized test to make sure 
that I'm comparing the latest two versions on common grounds instead of my 
bleeding edge patchwork attempt.



Some interesing things I found while googling are: 
https://wiki.archlinux.org/index.php/Pulseaudio#Glitches.2C_skips_or_crackling
Which suggest for the same symptoms I suffer, to disable the IOMMU. However, I 
don't have pulseaudio installed in Dom0, and the issue is in DomU. Plus only 
change was Xen package version installed.


Another one, even more interesing because it does involve Xen: 
http://www.gossamer-threads.com/lists/xen/users/282195#282987
This guy says that when he uses pciback.hide in the Boot Loader exactly like I 
do, he gets sound issues in the DomU, but that he succeded by instead letting 
Dom0 initialize the Sound Card, then using xl pci-assignable-add to disconnect 
it from Dom0 so it can be available for DomU. Which means that there could be 
an initilization issue. That Thread is dated one year ago and for Xen 4.2, but 
its too identical to my issue to not want to test this.


Because my test Dom0 is extremely minimalist, I need to check what I have to 
install so I can get sound output from Dom0 then proceed to try again output 
from DomU. Chances are that I end up installing a full blown Gnome or KDE on it 
with maybe Chromium and try a Youtube video. It also doesn't helps that my DomU 
selection is only WXP SP3, could help to add another Arch Linux DomU, giving 
that there are now a few more variables to test. Maybe the initialization issue 
is bound to the Realtek WXP SP3 Drivers and not other OSes.
Assuming you have the time and will, as you said that you have near identical 
Hardware, you may want to try to reproduce it yourself. There is indeed an 
issue somewhere related to Xen 4.4.1, but I doubt I can pinpoint what exactly 
it is. I will try to get more logs with the IOMMU setting, test without 
xen-pciback.hide, and post results, but chances are that you can do a more 
in-depth test of whatever I miss.                                       
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel