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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Oct 06, 2014 at 07:16:35PM -0300, Zir Blazer wrote:
> >> 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.                                     


The other thing that occured to me last night is that Xen 4.3 and Xen 4.4
have different versions of QEMU and BIOS. But your config has
'qemu-traditional' which has been unchanged between Xen 4.3 and
Xen 4.4. The only difference was how 'hvmloader' did things.

From the output from both 'xl dmesg' shows them nearly the same. Except this:

Detected Xen v4.4.1                                           | Detected Xen 
v4.3.2
.. snip..
 [03]: 00000000:00100000 - 00000000:3fc00000: RAM             |  [03]: 
00000000:00100000 - 00000000:3f800000: RAM
 HOLE: 00000000:3fc00000 - 00000000:fc000000                  |  HOLE: 
00000000:3f800000 - 00000000:fc000000
 [04]: 00000000:fc000000 - 00000001:00000000: RESERVED           [04]: 
00000000:fc000000 - 00000001:00000000: RESERVED

But that should not be an issue. If you feel like you could
try plopping Xen 4.4 hvmloader on your Xen 4.3 install for kicks.

You also do xen-pciback.hide, but since you are using the
same version of Linux that has quite limited impact. Was
there anything different in the Linux 'dmesg' when you
booted it under Xen 4.3 compared to Xen 4.4? Oh wait - you
are an awesome bug-reporter - you already included that!

[    0.000000] xen:events: Using 2-level ABI                  | [    0.000000] 
xen:events: Using FIFO-based ABI

Can you boot under Xen 4.4 Linux with 'xen.fifo=0' please?
That should disable that (in case it is that)

What kind of sounds issues is this? Is it poping with some
rhytm or hissing ? 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel