You are not logged in.
Hello,
I get "vfio: error no iommu_group for device"
Tell me what logs you need to help me please
GitHub | Git Server | Blog
Offline
Hello,
I get "vfio: error no iommu_group for device"
Tell me what logs you need to help me please
1) Check whether IOMMU is properly enabled
dmesg | grep -e DMAR -e IOMMU
for Intel or
dmesg | grep AMD-Vi
for AMD. If there is no output it may not be enabled in BIOS (check if it is), may not be enabled for your kernel (ensure you have
intel_iommu=on
for Intel or
iommu=pt iommu=1
as kernel parameter. All this assuming your CPU and motherboard do support VT-d. Feel free to provide more detail and the output of dmesg.
2) Check whether your device is bound to vfio-pci.
ls /sys/bus/pci/drivers/vfio-pci | grep 0000
will list the devices currently bound to vfio-pci, confirm that your device is there. If it is not, have a look at the steps listed in the first post. Feel free to provide more detail on how you are binding your device.
That's all I can think of but maybe there's other more knowledgeable persons here that can offer more advice.
Offline
Hello,
I get "vfio: error no iommu_group for device"
Tell me what logs you need to help me please
Most importantly, check that your CPU supports an IOMMU. If it's Intel, check the features on ark, http://ark.intel.com
Last edited by aw (2014-06-10 15:08:28)
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
ttouch wrote:Hello,
I get "vfio: error no iommu_group for device"
Tell me what logs you need to help me please1) Check whether IOMMU is properly enabled
dmesg | grep -e DMAR -e IOMMU
for Intel or
dmesg | grep AMD-Vi
for AMD. If there is no output it may not be enabled in BIOS (check if it is), may not be enabled for your kernel (ensure you have
intel_iommu=on
for Intel or
iommu=pt iommu=1
as kernel parameter. All this assuming your CPU and motherboard do support VT-d. Feel free to provide more detail and the output of dmesg.
2) Check whether your device is bound to vfio-pci.
ls /sys/bus/pci/drivers/vfio-pci | grep 0000
will list the devices currently bound to vfio-pci, confirm that your device is there. If it is not, have a look at the steps listed in the first post. Feel free to provide more detail on how you are binding your device.
That's all I can think of but maybe there's other more knowledgeable persons here that can offer more advice.
Yea, you're right. I got on dmesg after trying to vfio-bind: "vfio-pci: probe of 0000:02:00.0 failed with error -22"
I can't find if my CPU supports IOMMU (I am from mobile). It's i7 3820. I think it supports it
EDIT: I booted with "intel_iommu=on" and the device binds. Now, I just get a blank screen in qemu. is that normal? (I use the test qemu command you provided)
EDIT2: I added a cdrom device (entry you provided) and still blank screen. I booted with this "kvm_intel.emulate_invalid_guest_state=0" bit nothing changed (kvm_intel is built in).
Last edited by ttouch (2014-06-10 16:19:02)
GitHub | Git Server | Blog
Offline
I can't find if my CPU supports IOMMU (I am from mobile). It's i7 3820. I think it supports it
EDIT: I booted with "intel_iommu=on" and the device binds. Now, I just get a blank screen in qemu. is that normal? (I use the test qemu command you provided)
Yes http://ark.intel.com/products/63698/Int … o-3_80-GHz i7 3820 supports VT-d.
Blank screen is kind of normal, extra magic dust is needed for SeaBIOS to output to passed-through card (I do not remember what it was). If you booted valid OS boot image, the screen should show it. I recommend some Linux live CD, these take care to initialise the right set of drivers.
Offline
YES! IT WORKS!
thank you very much
I'll report if more errors appear
GitHub | Git Server | Blog
Offline
Is there any way to pivot the keyboard and mouse between host and guest?
Ultimately with one of the function keys of my Razer blackwidow ultimate.
GitHub | Git Server | Blog
Offline
Is there any way to pivot the keyboard and mouse between host and guest?
Ultimately with one of the function keys of my Razer blackwidow ultimate.
Try Synergy http://synergy-project.org/ I'm using the server on my Linux host and client on Windows VM.
Offline
ttouch wrote:Is there any way to pivot the keyboard and mouse between host and guest?
Ultimately with one of the function keys of my Razer blackwidow ultimate.Try Synergy http://synergy-project.org/ I'm using the server on my Linux host and client on Windows VM.
Thank you. I'll try it.
Also, can I boot my UEFI windows 8 installation (separate partition).
GitHub | Git Server | Blog
Offline
Hello,
I'm trying to Passthrough 2 GPUS to 2 diffrent Vm's, here is my specification "this the aim of this PC":
Motherboard : Asus z97-A
CPU: i7-4790
VGA at PCI-E x8 1: GeForce 8500 GT
VGA at PCI-E x8 2: Radeon HD 4870
Ram: 16 Gb Kingston 1600 Mhz
OS: Linux Mint 17 Qiana
Kernel : 3.15 RC2.
The GPU's, are a bit old (Yet the radeon still support every new game out there!), looking to upgrade according to the success.
I saw a post mentioning the drop of speed for PCI-E 3, I need to note, yes that's true, if the first PCI-Ex3 was populated you will get x16 speed, if 2 PCI-Ex3 are populated you will get x8 the speed, I don't know about using the 3 slots, but the speed will either drop or it won't work, that's for my motherboard at least.
Both my CPU and motherboard support VT-d,
I have enabled the support for 1) "intel virtualization technology", 2) "VT-d" and forced 3) "intel graphic" so, I do not need to block the driver's in the host >> right ?
I plan to use RMD "Remote Desktop" for connecting to the Vm's through the network, so I do not need any USB passthrough.
now... I need some help to start passing the GPU's...
Now i could make it all work with stock (from repos, no recompiling) software available:
Kernel: 3.15 (no patches)
Qemu 2.0.0
libvirt 1.2.2
virt-manager 1.0.1CPU AMD FX(tm)-8350 Eight-Core Processor
GPU radeon R9 270X
Motherboard SABERTOOTH 990FX R2.0This is on linux mint 17 (based on ubuntu 14.04 LTS). For libvirt i used default pc chipset (no manual xml editing!). Using emulated GPU for booting, OS switches to physical GPU later on during boot. Good to finally see this work without much hackery.
Could you please detail the booting step ?
What I'v done so far installing the independents ( Qemu 2.0.0, libvirt, virt-manager ), and asking above.
Offline
novist wrote:Now i could make it all work with stock (from repos, no recompiling) software available:
Kernel: 3.15 (no patches)
Qemu 2.0.0
libvirt 1.2.2
virt-manager 1.0.1CPU AMD FX(tm)-8350 Eight-Core Processor
GPU radeon R9 270X
Motherboard SABERTOOTH 990FX R2.0This is on linux mint 17 (based on ubuntu 14.04 LTS). For libvirt i used default pc chipset (no manual xml editing!). Using emulated GPU for booting, OS switches to physical GPU later on during boot. Good to finally see this work without much hackery.
Could you please detail the booting step ?
What I'v done so far installing the independents ( Qemu 2.0.0, libvirt, virt-manager ), and asking above.
Please do not expect novist's setup to work for you. Some people have had luck using secondary device passthrough with AMD cards, others have not. It will certainly not work for your NVIDIA card unless you plan to upgrade to a Quadro card. The most successful method is VGA assignment, for which you'll at a minimum need to patch your kernel with the i915 patch. You may also need the ACS override patch unless you can configure your cards to be in separate IOMMU groups by switching to different slots.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
abdullah wrote:novist wrote:Now i could make it all work with stock (from repos, no recompiling) software available:
Kernel: 3.15 (no patches)
Qemu 2.0.0
libvirt 1.2.2
virt-manager 1.0.1CPU AMD FX(tm)-8350 Eight-Core Processor
GPU radeon R9 270X
Motherboard SABERTOOTH 990FX R2.0This is on linux mint 17 (based on ubuntu 14.04 LTS). For libvirt i used default pc chipset (no manual xml editing!). Using emulated GPU for booting, OS switches to physical GPU later on during boot. Good to finally see this work without much hackery.
Could you please detail the booting step ?
What I'v done so far installing the independents ( Qemu 2.0.0, libvirt, virt-manager ), and asking above.
Please do not expect novist's setup to work for you. Some people have had luck using secondary device passthrough with AMD cards, others have not. It will certainly not work for your NVIDIA card unless you plan to upgrade to a Quadro card. The most successful method is VGA assignment, for which you'll at a minimum need to patch your kernel with the i915 patch. You may also need the ACS override patch unless you can configure your cards to be in separate IOMMU groups by switching to different slots.
From the first post "3.15 includes acs override patch, i935 vga arbiter fixes", the patch is already applied, isn't it ?
it only needs to work,
Offline
From the first post "3.15 includes acs override patch, i935 vga arbiter fixes", the patch is already applied, isn't it ?
it only needs to work,
No, that comment is really poorly worded. It's describing the tgz file, not what's upstream. Linux 3.15 proper does not include the ACS override patch or the i915 VGA arbiter patch.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
abdullah wrote:From the first post "3.15 includes acs override patch, i935 vga arbiter fixes", the patch is already applied, isn't it ?
it only needs to work,No, that comment is really poorly worded. It's describing the tgz file, not what's upstream. Linux 3.15 proper does not include the ACS override patch or the i915 VGA arbiter patch.
Oh...
how about my other configuration ? Since I forced the using integrated intel HD4600, Do I still need to block the drivers for the other cards ?
Offline
aw wrote:abdullah wrote:From the first post "3.15 includes acs override patch, i935 vga arbiter fixes", the patch is already applied, isn't it ?
it only needs to work,No, that comment is really poorly worded. It's describing the tgz file, not what's upstream. Linux 3.15 proper does not include the ACS override patch or the i915 VGA arbiter patch.
Oh...
how about my other configuration ? Since I forced the using integrated intel HD4600, Do I still need to block the drivers for the other cards ?
I don't really know what you mean by "forced intel graphic", but I assume that just means setting Intel as the primary display for the host. In that case, yes you still need to prevent nouveau/radeon from binding to the devices you intend to assign.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
...
Using kernel 3.15 I have host display corruption and non-working VGA passthrough (host with igfx, AMD HD6450 for passthrough) despite having applied the i915_315 VGA arbiter patch.
...
this brief description reminds me of my situation:
https://bbs.archlinux.org/viewtopic.php … 5#p1419025
https://bbs.archlinux.org/viewtopic.php … 2#p1419322
https://bbs.archlinux.org/viewtopic.php … 8#p1420298
Offline
I built two versions of the 3.15 kernel, one with and one without the override_acs patch from the archive linked in the first post. Both kernel sources have the i915_315 patch applied. I have two issues, broken VGA passthrough (working on 3.14) and not being able to passthrough onboard SATA.
I had missed
Be sure to boot with i915.enable_hd_vgaarb=1 with this version.
so the i915 issue is taken care of. Still in the dark regarding the other device passthrough as per post 2025. Any suggestions to move on with my ACS issues are greatly appreciated.
Offline
siddharta wrote:I built two versions of the 3.15 kernel, one with and one without the override_acs patch from the archive linked in the first post. Both kernel sources have the i915_315 patch applied. I have two issues, broken VGA passthrough (working on 3.14) and not being able to passthrough onboard SATA.
I had missed
aw wrote:Be sure to boot with i915.enable_hd_vgaarb=1 with this version.
so the i915 issue is taken care of. Still in the dark regarding the other device passthrough as per post 2025. Any suggestions to move on with my ACS issues are greatly appreciated.
You haven't said why using multifunction or ID options to the override failed. What ID did you use? What was the resulting change in /sys/kernel/iommu_groups?
Last edited by aw (2014-06-10 20:38:45)
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
You haven't said why using multifunction of id options to the override failed. What ID did you use? What was the resulting change in /sys/kernel/iommu_groups?
The device I'm trying to passthrough is
00:1f.2 SATA controller [0106]: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e02] (rev 04)
Subsystem: ASRock Incorporation Motherboard [1849:1e02]
Kernel driver in use: vfio-pci
1) with kernel 3.15.0 (patched with i915 and override_acs patches) and kernel parameters intel_iommu=on i915.enable_hd_vgaarb=1 (and therefore the override_acs disabled) the iommu groups I'm looking at for passthrough are
### Group 1 ###
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450]
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Caicos HDMI Audio [Radeon HD 6400 Series]
### Group 10 ###
00:1f.0 ISA bridge: Intel Corporation H77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
2) with pcie_acs_override=downstream the graphics card devices break out of iommu group 1 and move to group 11. All other groups remain as they were.
3) with pcie_acs_override=multifunction the result is the same as in 1)
4) with pcie_acs_override=id:1849:1e02 the result is again the same as in 1)
Hope this helps. Thanks again.
Last edited by siddharta (2014-06-10 20:51:50)
Offline
aw wrote:You haven't said why using multifunction of id options to the override failed. What ID did you use? What was the resulting change in /sys/kernel/iommu_groups?
The device I'm trying to passthrough is
00:1f.2 SATA controller [0106]: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e02] (rev 04) Subsystem: ASRock Incorporation Motherboard [1849:1e02] Kernel driver in use: vfio-pci
1) with kernel 3.15.0 (patched with i915 and override_acs patches) and kernel parameters intel_iommu=on i915.enable_hd_vgaarb=1 (and therefore the override_acs disabled) the iommu groups I'm looking at for passthrough are
### Group 1 ### 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450] 01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Caicos HDMI Audio [Radeon HD 6400 Series] ### Group 10 ### 00:1f.0 ISA bridge: Intel Corporation H77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
2) with pcie_acs_override=downstream the graphics card devices break out of iommu group 1 and move to group 11. All other groups remain as they were.
3) with pcie_acs_override=multifunction the result is the same as in 1)
4) with pcie_acs_override=id:1849:1e02 the result is again the same as in 1)
Hope this helps. Thanks again.
Lemme guess, "lspci -vvv -s 00:1f." doesn't show a PCIe capability for any of those devices, right? So as it is, the acs override patch isn't going to split those devices, sorry. You can hack up the patch some more or use pci-assign, but really the only supportable option is to get a separate SATA card to install.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
Lemme guess, "lspci -vvv -s 00:1f." doesn't show a PCIe capability for any of those devices, right? So as it is, the acs override patch isn't going to split those devices, sorry. You can hack up the patch some more or use pci-assign, but really the only supportable option is to get a separate SATA card to install.
It does for the SATA controller (unless I'm reading this wrong) but not for the other devices. All devices in the iommu group would need to have PCIe capability? My understanding here is obviously limited.
00:1f.0 ISA bridge: Intel Corporation H77 Express Chipset LPC Controller (rev 04)
Subsystem: ASRock Incorporation Device 1e4a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
Subsystem: ASRock Incorporation Motherboard
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin B routed to IRQ 19
Region 0: I/O ports at f0b0 [size=8]
Region 1: I/O ports at f0a0 [size=4]
Region 2: I/O ports at f090 [size=8]
Region 3: I/O ports at f080 [size=4]
Region 4: I/O ports at f060 [size=32]
Region 5: Memory at f7f12000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: fee002d8 Data: 0000
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
Capabilities: [b0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: vfio-pci
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
Subsystem: ASRock Incorporation Motherboard
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 18
Region 0: Memory at f7f11000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at f040 [size=32]
Kernel modules: i2c_i801
edit: yes it does look like I may be reading this wrong, when comparing to the output of lspci -vvv -s 01:00 which are the graphics card devices -
Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
edit 2: PCI assign doesn't work for me as it did in QEMU 1.6.2 and kernel 3.11. I get the same complaint about the iommu group not being viable. Has PCI assign been removed as a passthrough mechanism in favor of vfio?
Last edited by siddharta (2014-06-10 21:19:24)
Offline
edit 2: PCI assign doesn't work for me as it did in QEMU 1.6.2 and kernel 3.11. I get the same complaint about the iommu group not being viable. Has PCI assign been removed as a passthrough mechanism in favor of vfio?
When attempting PCI assign of the SATA controller with the following guest definition
<domain type='kvm'>
<name>vm-storage-test</name>
<uuid>850b3562-bb54-d1df-2071-1c0ebb30e9ee</uuid>
<memory unit='KiB'>524288</memory>
<currentMemory unit='KiB'>524288</currentMemory>
<vcpu placement='static'>1</vcpu>
<os>
<type arch='x86_64' machine='pc-i440fx-2.0'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/qemu-kvm</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/var/lib/libvirt/images/vm-storage-2.vhd'/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</disk>
<controller type='usb' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
</controller>
<controller type='pci' index='0' model='pci-root'/>
<interface type='bridge'>
<mac address='52:54:00:40:4f:8f'/>
<source bridge='br0'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<graphics type='vnc' port='-1' autoport='yes'/>
<video>
<model type='cirrus' vram='9216' heads='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</hostdev>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</memballoon>
</devices>
</domain>
the error is the same as when attempting to passthrough the device with vfio.
Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: -device vfio-pci,host=00:1f.2,id=hostdev0,bus=pci.0,addr=0x7: vfio: error, group 10 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver.
qemu-system-x86_64: -device vfio-pci,host=00:1f.2,id=hostdev0,bus=pci.0,addr=0x7: vfio: failed to get group 10
qemu-system-x86_64: -device vfio-pci,host=00:1f.2,id=hostdev0,bus=pci.0,addr=0x7: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=00:1f.2,id=hostdev0,bus=pci.0,addr=0x7: Device 'vfio-pci' could not be initialized
Very weird (to me). The SATA controller is no longer bound to vfio-pci at this time.
Last edited by siddharta (2014-06-10 21:46:20)
Offline
the error is the same as when attempting to passthrough the device with vfio.
Error starting domain: internal error: process exited while connecting to monitor: qemu-system-x86_64: -device vfio-pci,host=00:1f.2,id=hostdev0,bus=pci.0,addr=0x7: vfio: error, group 10 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver. qemu-system-x86_64: -device vfio-pci,host=00:1f.2,id=hostdev0,bus=pci.0,addr=0x7: vfio: failed to get group 10 qemu-system-x86_64: -device vfio-pci,host=00:1f.2,id=hostdev0,bus=pci.0,addr=0x7: Device initialization failed. qemu-system-x86_64: -device vfio-pci,host=00:1f.2,id=hostdev0,bus=pci.0,addr=0x7: Device 'vfio-pci' could not be initialized
Very weird (to me). The SATA controller is no longer bound to vfio-pci at this time.
You're still using vfio, see the driver option of the hostdev device http://libvirt.org/formatdomain.html#el … tDevSubsys
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
You're still using vfio, see the driver option of the hostdev device http://libvirt.org/formatdomain.html#el … tDevSubsys
See, not weird at all. . Thanks. With
<hostdev mode='subsystem' type='pci' managed='yes'>
<driver name='kvm'/>
<source>
<address domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</hostdev>
the SATA controller is peachy. Now to see about USB. Thanks Alex, if you're ever in Las Palmas I'd gladly stand you a beer.
Offline
rabcor maybe it is possible to use second GPU for host. after all if windows can switch to second GPU on boot then linux should be able to do this even more so. sideeffect of that would be boot messages showing on first gpu early on boot including grub menus. if i were you i would try passing through first gpu same way like you do with second and see what happens. it might work.
Of course it's possible, I'm doing it.
Dunno, I am so used to Linux command line over ssh, that I do not care to see its GUI at all. I guess I am not the only one.
Still, Linux should work with second GPU, I think the challenge is to:
1. get vgacon to give away primary GPU before you start the guest
2. get X to ignore primary GPU
PCI-stub works, X won't even touch it (as in it doesn't show up in RandR providers and whatnot).
As for the bootup, I can set in the BIOS which PCI slot to use as primary.
I'm passing a 660Ti and using a 640 for the host. I'll write a detailed post later.
Thanks Alex, if you're ever in Las Palmas I'd gladly stand you a beer.
I'll second that. Whenever you're in Hungary :--D
Offline