Hi again and sorry for the double post, regarding the Audio: I tried two different things at the same time, when I got the improvement on Haswell. The actual reason was the dmix alsa device having a higher sampling rate than the qemu output. Output further clears, when the output rate is a divisor of the dmix alsa device rate, i.e. 44100 is worse for 96000 than 48000. It is still not perfectly clear, but I can bear with that. Sorry for the wild guess.
Best regards, Manuel PS: qemu-2.8.0 broke my Haswell VM due to the following issue with USB passthrough. Didn’t affect my Skylake VM, but that has just the mouse in passthrough. https://www.reddit.com/r/VFIO/comments/5k2ltz/warning_qemu_280_causes_issues_with_usb/ > Hi Alex, > > for me, the patch also didn’t have any impact (negative or > positive). I’ve used this on a Skylake Laptop (Lenovo T460). Actually > the passthrough tended to work out of the box with the configuration > copied from my Haswell Desktop. I do/did run into a few issues though: > > 1. The patch could not be applied to qemu-2.8.0 or git, which was > unfortunate. I’m not sure against which branch or commit it was written, > but especially the hwaddr line cutting off the error message seems odd. > Manually applied the advertised changes into a new one working against > v2.8.0: > http://pastebin.com/1LJXZskq > > 2. Occasionally (maybe 50% of boots) the VM will crash at Windows > loading screen. Could be related to the following thread, although I > don’t get a kernel oops. > https://www.redhat.com/archives/vfio-users/2016-December/msg00064.html > qemu crash output: > http://pastebin.com/36rnB5Zq > > 3. For some reason I couldn’t allocate 6 1GB hugepages, although both > computers (Haswell desktop/Skylake laptop) have 8 GB memory and > regardless of specifying them as kernel boot parameter or echoing them > into /proc/sys/vm/nr_hugepages in initrd. Also the boot parameter seemed > to have no allocation effect at all, which was only achieved by manually > echoing into the sys node, resulting 5 pages being allocated. Slightly > confusing, that an rsynced system behaves completely different on other > hardware. Network relevant deviations were done by abusing portage’s > config protect feature and rsync’s filter lists. Anyway, works (almost) > fine with 5 hugepages. > > 4. I still have trouble assigning an ALSA device to the emulated ich9 > card. It works, but the Audio is distorted. I worked around this with my > Haswell by passing through the Intel PCH and using the USB DAC as common > sound device. This somehow fixed the distortion, although I still have > some popping sounds occasionally (as if the DAC was in passthrough). > > On my Skylake laptop the PCH audio device is unfortunately not > isolated. Almost half of the processor is on the same bridge including > MMU and SMbus and ISA bridge. So I can’t work around in the same > manner. Passing through the DAC works with the same quality. > > Could this somehow be related to the IGD being passed through and still > sharing any resources with the Audio chipset? I didn’t get resolving > tips on libvirt-users mailing list. > > Best regards, > Manuel > >> Hi Alex, >> >> For me it did no difference, but all in all, my case was far away from >> getting working because of the intrusive simplefb jumping into the field. >> >> Thanks! >> >> José. >> >> On Monday 12 December 2016 15:24:40 Alex Williamson wrote: >>> Hi, >>> >>> I think maybe we've found the issue that many of you with Skylake or >>> newer systems were seeing with IGD assignment. There's a wraparound >>> issue with the GTT programming, as discovered by Alexander Indenbaum. >>> I still don't have access to anything newer than Broadwell, so I'm >>> interested in test reports from anyone that's currently using IGD >>> assignment or tried previously and maybe didn't get any output or >>> garbled output, whether on Skylake, Kabylake, or regression testing on >>> older IGD as well. Please add the following patch to your QEMU build >>> and report if it breaks anything, fixes anything, or even if it stays >>> the same: >>> >>> https://lists.nongnu.org/archive/html/qemu-devel/2016-12/msg01600.html >>> >>> Thanks, >>> Alex >>> >>> _______________________________________________ >>> vfio-users mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/vfio-users >> >> >> _______________________________________________ >> vfio-users mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/vfio-users _______________________________________________ vfio-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/vfio-users
