[vfio-users] amd gpu not being seen

Wed Sep 30 07:55:39 UTC 2015

Alright, i've studied your dmesg(fell asleep in one place), so:
You should blacklist the radeon driver. It seems like it's interfering not
only with vfio, but somehow manages to screw up nvidia host driver.
And there is a high possibility that you should remove that wireless
adapter and plug your third GPU there, because iommu grouping may be messed
up.
Your host GPU is plugged in the first slot and should be the only one doing
VGA. But for some reason it is not.

After blacklisting the radeon driver, you should reinstall the guest system.
On Sep 29, 2015 6:23 PM, "Ryan Clawfish" <chimmychainsaw at hotmail.com> wrote:

> The output was huge and I thought only the vfio entries were relevant. My
> bad. I'm using vfio-pci because it's recommended on the arch wiki. I have
> not yet tried pci-stub.
>
> I've added: *options vfio-pci ids=1002:6798,1002:aaa0* to
> /etc/modprobe.d/vfio.conf
>
> everything else is on http://pastebin.com/3DA3wUBd
>
>
> ------------------------------
> Date: Tue, 29 Sep 2015 17:43:02 +0300
> Subject: Re: [vfio-users] amd gpu not being seen
> From: ihatethisfield at gmail.com
> To: chimmychainsaw at hotmail.com
> CC: vfio-users at redhat.com
>
> Why did you grep...
> Post the full one on pastebin or search for whatever using VGA or that
> GPUs. Do you use any kind of pre-binding(vfio-pci.ids=...) or pci-stub?
> On Sep 29, 2015 5:36 PM, "Ryan Clawfish" <chimmychainsaw at hotmail.com>
> wrote:
>
> Hotmail really needs to start accepting code tags, it would make things so
> much neater.
>
> I'm using an fx 8350 with an asus m5a99 pro R2.0 motherboard.
>
> * lspci -nn*
> 04:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
> [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] [1002:6798]
> 04:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti
> XT HDMI Audio [Radeon HD 7970 Series] [1002:aaa0]
>
> *[ryan at earth-archbox ~]$ dmesg | grep -i vfio*
> [    1.066842] VFIO - User Level meta-driver version: 0.3
> [    1.079992] vfio_pci: add [1002:6798[ffff:ffff]] class 0x000000/00000000
> [    1.093349] vfio_pci: add [1002:aaa0[ffff:ffff]] class 0x000000/00000000
> [  108.858636] vfio-pci 0000:04:00.0: enabling device (0000 -> 0003)
> [  108.858820] vfio_ecap_init: 0000:04:00.0 hiding ecap 0x19 at 0x270
> [  108.858829] vfio_ecap_init: 0000:04:00.0 hiding ecap 0x1b at 0x2d0
> [  108.875285] vfio-pci 0000:04:00.1: enabling device (0000 -> 0002)
> [ 1284.893125] vfio_ecap_init: 0000:04:00.0 hiding ecap 0x19 at 0x270
> [ 1284.893133] vfio_ecap_init: 0000:04:00.0 hiding ecap 0x1b at 0x2d0
> [ 1284.909667] vfio-pci 0000:04:00.1: enabling device (0400 -> 0402)
> [ 1519.790793] vfio_ecap_init: 0000:04:00.0 hiding ecap 0x19 at 0x270
> [ 1519.790805] vfio_ecap_init: 0000:04:00.0 hiding ecap 0x1b at 0x2d0
> [ 1519.810519] vfio-pci 0000:04:00.1: enabling device (0400 -> 0402)
>
> * Hostdev*
> </video>
>     <hostdev mode='subsystem' type='pci' managed='yes'>
>       <source>
>         <address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
>       </source>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x08'
> function='0x0'/>
>     </hostdev>
>     <hostdev mode='subsystem' type='pci' managed='yes'>
>       <source>
>         <address domain='0x0000' bus='0x04' slot='0x00' function='0x1'/>
>       </source>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x09'
> function='0x0'/>
>     </hostdev>
>
> So you managed to get crossfire inside the emulation? I didn't think it
> was possible but that would be beyond cool. Pain in the ass sure but still
> cool as hell.
>
> also: In my pre coffee daze i accidentally replied to ihatethisfield and
> not the mailing list. Sorry about that.
>
>
> ------------------------------
> Date: Tue, 29 Sep 2015 07:46:23 +0300
> Subject: Re: [vfio-users] amd gpu not being seen
> From: ihatethisfield at gmail.com
> To: chimmychainsaw at hotmail.com
> CC: vfio-users at redhat.com
>
> Your attached XML file lacks the most important part: <hostdev> entries
> with your GPUs.
> Tell us about your CPU-MB combo and do lspci -nn and find all your needed
> devices in their respective iommu groups. And it would be good to see your
> dmesg, maybe you've forgot to blacklist some driver or something else
> tampers with VGA somehow.
>
> Also, on my 2xHD7750 crossfire works flawlessly. They don't need a bridge
> to interconnect, but your cards might need it.
> On Sep 29, 2015 4:26 AM, "Ryan Clawfish" <chimmychainsaw at hotmail.com>
> wrote:
>
> I'm rather happy with 2x 280x's. Hopefully i can use linux virtualization
> for convinence gaming and reboot into a windows partition when i want
> insane crossfire graphics.
>
> To be honest i'm a noob at this and i don't really know what the hell i'm
> doing. I'm mostly following the arch wiki guide
> https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF  Because
> /dev/vfios/17 did not exist I decided to reinstall arch and restart the
> process from scratch, roughly documenting my steps. Here's what i did.
>
> installed qemu and rpmextract
> extracted the gerd hoffmons eufi and moved it to /usr/share
> downloaded libvirt
> enabled libvirt and start it
> installed ebtables dnsmasq  bridge-utils and bsd-netcat
> added amd_iommu=on to /etc/default/grub, regenerated grub and rebuilt
> mkinitpcio
> added modprobe vfio-pci
> ran mkinitpcio
> /etc/libvirt/qemu.conf added root permissions + /dev/vfio/17
> created raw file for emulated hdd
> installed virt-manager
> sudo cp /usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd
> /usr/share/ovmf/OVMF-win10.fd #pointless?
> sudo ln -s /usr/share/ovmf/OVMF-win10.fd
> /usr/share/ovmf/OVMF-win10.fd                      #pointless
> added uefi into in the os section of my xml file:
>        <loader readonly='yes'
> type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
>        <nvram
> template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'/>
> installed windows 10
> installed radeon drivers
> added target pci (gpu) from virt-manager gui
>
> When i add the my gpu  the uefi is delayed and booting windows 10 takes
> forever. There are lots of artifacts and it lags to the point of being
> completely unusable.  I've tried adding my card via virt-manager gui and
> via the (depreciated?)<qemu:commandline>. Both have the same effect.
>
> Here's my xml virt config file http://pastebin.com/sNxvXiQ6
>
>
>
> ------------------------------
> Date: Mon, 28 Sep 2015 09:40:22 -0600
> Subject: Re: [vfio-users] amd gpu not being seen
> From: alex.l.williamson at gmail.com
> To: chimmychainsaw at hotmail.com
> CC: vfio-users at redhat.com
>
> On Mon, Sep 28, 2015 at 9:12 AM, Ryan Clawfish <chimmychainsaw at hotmail.com
> > wrote:
>
> My main issue is i keep getting an error saying "failed to get group 17"
> and "/dev/vfio/17 does not exist."  If i ls -a my /dev , i see /dev/vfio
> does not exist. I created it using mkdir, chmod 666 it and added it in
> /etc/libvirt/qemu.conf but the error persists.
>
>
> So all along, you've probably been trying to use legacy KVM device
> assignment, which led too the Code 43 with the GeForce card.  Too bad,
> IMHO, the 770 was a better card.  vfio has been the default for PCI hostdev
> devices since libvirt 1.1.3 and /dev/vfio/ should be present even before
> vfio is load since kernel v3.14.  Are you even building vfio support into
> your kernel?
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
> http://pastebin.com/HrCWcd6Shttp://pastebin.com/HrCWcd6Shttp://pastebin.com/HrCWcd6S
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20150930/6bdb12c4/attachment.htm>