[vfio-users] IGD assignment users, please test

Manuel Ullmann ullman.alias at posteo.de
Thu Jan 5 17:41:11 UTC 2017


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
>>> vfio-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/vfio-users
>>
>>
>> _______________________________________________
>> vfio-users mailing list
>> vfio-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/vfio-users




More information about the vfio-users mailing list