<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 5, 2017 at 10:23 PM, Thiago Ramon <span dir="ltr"><<a href="mailto:thiagoramon@gmail.com" target="_blank">thiagoramon@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail-h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div><br></div></div></div><div class="gmail_extra">Here, dropped the raw message in pastebin: <a href="https://pastebin.com/hfJ6ryJg" target="_blank">https://pastebin.<wbr>com/hfJ6ryJg</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">That particular run was trying to pass the 980 Ti, which is the boot device, and which probably had something else prodding at it (I'll give it a try again and check what else was attaching to it). I've mostly focused on passing the 1060 though, which doesn't get touched by anything but vfio-pci, and also doesn't show any mmap issues, here's the last QEMU run with SeaBIOS:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://pastebin.com/DEPpewCH" target="_blank">https://pastebin.com/DEPpewCH</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">And the last one from OVMF:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://pastebin.com/L7gkrm36" target="_blank">https://pastebin.com/L7gkrm36</a><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">On the kernel log, I only get the vfio_bar_restore messages. One interesting and consistent pattern is that SeaBIOS always generate 2 pairs of warnings (one for GPU, one audio), while OVMF generates quite a bit (dozen+, don't have a log handy). Probably not relevant, as apparently the failure happens before the first message anyway.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Another detail that may be relevant: Whenever I try a passthrough (and fail), the kernel fails to soft restart. It gets to the last stage where it would do a soft reset but the console just sits there. Could this just be vfio_pci trying to do something with the unresponsive card, or something else that may be a clue to what's going on?</div></div></blockquote><div><br></div><div>Yep, here's what I suspected about the D3 warning:</div><div><br></div><div><div>>PCI state after passthrough attempt:</div><div>> 29:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM200 [GeForce GTX 980 Ti] [10de:17c8] (rev ff) (prog-if ff)</div><div>>   !!! Unknown header type 7f</div><div>>   Kernel driver in use: vfio-pci</div><div>>   Kernel modules: nouveau, nvidia_drm, nvidia</div><div>></div><div>> 29:00.1 Audio device [0403]: NVIDIA Corporation GM200 High Definition Audio [10de:0fb0] (rev ff) (prog-if ff)</div><div>>   !!! Unknown header type 7f</div><div>>   Kernel driver in use: vfio-pci</div><div>>   Kernel modules: snd_hda_intel</div></div><div><br></div><div>The card isn't actually stuck in D3, it's basically disappeared from the bus and all reads from config space are returning -1, which is indistinguishable from from D3 power state for the bits that tell us the power state.  This is probably the result of doing a bus reset, but that's also our only way of putting the device back to a known state before starting it in the VM.  You might try to see if you can reproduce this result manually with setpci.  We do a bus reset by finding the bridge upstream of the device, lspci -t is handy for this with a tree view of the PCI topology.  As an example:</div><div><br></div><div><a href="https://pastebin.com/c3URT6vx">https://pastebin.com/c3URT6vx</a><br></div><div><br></div><div>Bus numbers are shown in brackets, so if I want the parent bridge of device 01:00.0, look to the left of [01]--00.0 to find 01.0.  This is attached to the root bus at [0000:00], so the full address of the parent bridge is 0000:00:01.0.</div><div><br></div><div>We can access the bridge control register using</div><div><br></div><div># setpci -s 0000:00:01.0 BRIDGE_CONTROL</div><div><br></div><div>The secondary bus reset bit is 0x40.  We want to set this bit:</div><div><br></div><div># setpci -s 0000:00:01.0 BRIDGE_CONTROL=40:40<br></div><div><br></div><div>Then clear it:</div><div><br></div><div><div># setpci -s 0000:00:01.0 BRIDGE_CONTROL=00:40</div></div><div><br></div><div>Then run lspci on the bus to see if the device is still present.  In your case it would be bus 29, so you'd run</div><div><br></div><div># lspci -vvv -s 0000:29:</div><div><br></div><div>Do you get output like above with the 'Unknown header type 7f' or a complete listing of the device?  Be sure to reboot the system after running this test, regardless of the result the device will be re-initialized, and clearly nothing should be using the device while doing this.  If the graphics card doesn't recover from a bus reset, then something about this system setup is not compatible with this use case.  Thanks,</div><div><br></div><div>Alex</div></div></div></div>