<div dir="ltr">I have to (cautiously) say that removing audio passthrough seems to help with this issue. I already had twice the number of restarts it usually takes to freeze it and it is still going strong. I always had it bound to vfio-pci and now I just removed the audio part from the shell script I use to start my VMs.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 6:25 AM, Alex Williamson <span dir="ltr"><<a href="mailto:alex.williamson@redhat.com" target="_blank">alex.williamson@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 18 Feb 2016 06:00:59 -0800<br>
Nick Sukharev <<a href="mailto:nicksukharev@gmail.com">nicksukharev@gmail.com</a>> wrote:<br>
<br>
> So, if I am not using virsh, would it be sufficient to just remove audio<br>
> devices from my shell script that starts qemu? I am also not using them and<br>
> just thought I need to pass them to make AMD drivers happy. I am happy with<br>
> virtual audio provided by QEMU (and have multiple cards so wiring their<br>
> audio output to some speakers would be a project just by itself)<br>
<br>
</span>In the case of the GPU audio function, you can't simply ignore it<br>
because it's part of the same IOMMU group as the GPU itself.  It needs<br>
to be bound to vfio-pci or pci-stub or else you can't use the group<br>
with the GPU at all.  You don't necessarily need to assign it to the<br>
guest though.  The problem suspected here would occur when the devices<br>
are bound back to the host drivers.  You can easily just not do that if<br>
you're using a script, that's effectively what the libvirt instructions<br>
do.  If you really just don't want to deal with a device at all, you<br>
can do a software hot unplug (echo 1> /sys/bus/pci/devices/.../remove).<br>
</blockquote></div><br></div>