im trying to bind my spare radeon card to pci-stub on kubuntu 15.04, for the purposes of KVM gaming. these are my boot options and anything else related to pci-stub from dmesg
i grepped for radeon in my dmesg output, and indeed its only claiming the sound output device and radeons taking the graphics device, anyone know what the hell is going on?
dmesg | grep radeon
[ 1.931101] [drm] radeon kernel modesetting enabled.
[ 1.935185] fb: switching to radeondrmfb from VESA VGA
[ 1.935720] radeon 0000:01:00.0: VRAM: 3072M 0x0000000000000000 - 0x00000000BFFFFFFF (3072M used)
[ 1.935722] radeon 0000:01:00.0: GTT: 1024M 0x00000000C0000000 - 0x00000000FFFFFFFF
[ 1.935834] [drm] radeon: 3072M of VRAM memory ready
[ 1.935835] [drm] radeon: 1024M of GTT memory ready.
[ 1.941527] [drm] radeon: dpm initialized
[ 1.958642] radeon 0000:01:00.0: WB enabled
[ 1.958644] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x00000000c0000c00 and cpu addr 0xffff880434f56c00
[ 1.958646] radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x00000000c0000c04 and cpu addr 0xffff880434f56c04
[ 1.958648] radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x00000000c0000c08 and cpu addr 0xffff880434f56c08
[ 1.958649] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x00000000c0000c0c and cpu addr 0xffff880434f56c0c
[ 1.958651] radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x00000000c0000c10 and cpu addr 0xffff880434f56c10
[ 1.959065] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc90011cb5a18
[ 1.959069] radeon 0000:01:00.0: radeon: MSI limited to 32-bit
[ 1.959096] radeon 0000:01:00.0: radeon: using MSI.
[ 1.959119] [drm] radeon: irq initialized.
[ 3.098559] fbcon: radeondrmfb (fb0) is primary device
[ 3.098620] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[ 3.098622] radeon 0000:01:00.0: registered panic notifier
[ 3.100680] [drm] Initialized radeon 2.40.0 20080528 for 0000:01:00.0 on minor 0
[ 3.100725] radeon 0000:02:00.0: enabling device (0000 -> 0003)
[ 3.219006] radeon 0000:02:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[ 3.219009] radeon 0000:02:00.0: GTT: 1024M 0x0000000020000000 - 0x000000005FFFFFFF
[ 3.219021] [drm] radeon: 512M of VRAM memory ready
[ 3.219022] [drm] radeon: 1024M of GTT memory ready.
[ 3.223486] [drm] radeon: dpm initialized
[ 3.224604] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0
[ 3.228822] radeon 0000:02:00.0: WB enabled
[ 3.228825] radeon 0000:02:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff880035accc00
[ 3.228827] radeon 0000:02:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff880035accc0c
[ 3.231934] radeon 0000:02:00.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0xffffc90013bb2118
[ 3.231939] radeon 0000:02:00.0: radeon: MSI limited to 32-bit
[ 3.231965] radeon 0000:02:00.0: radeon: using MSI.
[ 3.232007] [drm] radeon: irq initialized.
[ 4.096027] radeon 0000:02:00.0: No connectors reported connected with modes
[ 4.098247] radeon 0000:02:00.0: fb1: radeondrmfb frame buffer device
[ 4.098338] [drm] Initialized radeon 2.40.0 20080528 for 0000:02:00.0 on minor 1
lspci | Radeon
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT HDMI Audio [Radeon HD 7970 Series]
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]
02:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Caicos HDMI Audio [Radeon HD 6400 Series]
lspci -n | grep 02:00.
02:00.0 0300: 1002:6779
02:00.1 0403: 1002:aa98
uname -a
Linux navi 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
I wish I had the answer but I don't everything from my little bit of knowledge looks correct, but I've never successfully completed a pci pass through on a debian distro so I'm not really sure, I'm confident someone will come along with the correct answer....
Fedora 22 .......works like a charm passing a R9 270x through to Win7, I have the common choppy audio playing some games but for the most part I'm very pleased with the setup.
I had that experience with both Suse and Ubuntu, never could get a stable install that didn't cause issues but Fedora been pretty stable for my hardware.
Might be a stupid question but your hardware does support IOMMU?
Dang.....I saw that wasn't in the boot parameters but I don't know enough about it to know if it was being called from somewhere else since his configuration doesn't look like mine. ;)
amd_iommu=on iommu=pt pci-stub.ids=xxxx:xxxx,xxxx:xxxx or something very much like this...and it is in this order which I don't know if it makes a difference, but I'd think you'd want to call iommu=on before adding the pci-stub but I'm not sure if the order makes much difference.
You might also look at this....http://vfio.blogspot.com/
I basically followed Alex's guide making modification where needed, I didn't use the advanced parsing, just the ids.
As far as hardware its a AMD 8370 cpu, Asrock 990fx fatality MB.
And at this point I should say if you have a Intel CPU the line is intel_iommu=on but I'm sure you know that.
One other thing I thought of is I'm using the default AMD video driver that is included in Fedora's kernel (open source) I did not install any other PPA or AMD proprietary video driver in the host, but did of course install the AMD windows drivers in the guest once the pass through was successful, the only reason I'm mentioning this is I thought I read awhile back that the proprietary AMD driver caused a issue in pass through but I could be mistaken about that.
well, im going to add "iommu=pt" to the kernel args, and see if that helps, if not theres the possibility of downloading and compiling kernel v4.1 and passing the devices straight to vfio-pci instead, or i could use xen-pciback and give that a shot
I know what you mean, vifo-pci was my next step if the pci-stub didn't work, but it did for me, do you know if the order makes any difference? my logic tells me it should but I've seen other instances where as long as it was included placement didn't matter.
so i took a look round, and it seems that the solution with xens pciback is either to compile it in to the kernel, or load it before the driver for that module via modprobe.d, so i decided its probably worth trying this with pci_stub first. am i going to have a bad time if i go with this in /etc/modprobe.d/radeon-pci-stub.conf?