You are not logged in.
So I've discovered what I believe to be my problem, but I'm confused why nobody else seems to be hitting it.
https://lists.gnu.org/archive/html/qemu … 01858.html
That's what's hitting me - I'm getting c0000221 stop's on boot on my VM, at this point, and seemingly this is due to virtio-scsi. I wonder why nobody else is hitting this?
EDIT: Of course, starting over with a fresh Win7 x64 install using ide instead of virtio, it works fine up until I try to install Windows updates, even only a few of them, at which point after reboot it dies with a different BSOD, code c000021a. -sigh-
Sorry for the OT here, but I've also been hitting this issue. I'm not able to install or boot Windows 8.1 with virtio-scsi and qemu 2.0.
Just to let others know that the issue is known:
https://lists.gnu.org/archive/html/qemu … 02280.html
Offline
myweb wrote:aw wrote:This particular bridge likely produces a WARN_ON when booting the kernel on a VT-d system because it lacks a PCIe capability (in violation of the PCIe spec). As a result, I doubt that the IOMMU tables are getting setup correct for devices behind the bridge. I've actually been working on trying to fix this for the last couple weeks. In any case, assigning the bridge to the guest is always wrong, so I'd start with that. I'll hopefully be posting patches to fix the situation with this bridge this week or next.
This is amazing news!
Could you please specify where are you going to upload/write info about fix (twitter, github, ... - how to follow news)?I posted the patches today, here's a link to the header with a description:
http://www.spinics.net/lists/linux-pci/msg30941.html
For your convenience, I've also pushed a branch out to github that is 3.15-rc3 + these changes, you'll need to add whatever other patches (i915/acs) on top:
git://github.com/awilliam/linux-vfio.git
branch: dma-alias
Let me know how it goes.
Alex, thank you!
I have specified:
source=("git://github.com/awilliam/linux-vfio.git#branch=dma-alias"
in PKGBUILD, I am not sure that is right. Could you please specify how to check that sourced are exactly from dma-alias branch?
Offline
aw wrote:myweb wrote:This is amazing news!
Could you please specify where are you going to upload/write info about fix (twitter, github, ... - how to follow news)?I posted the patches today, here's a link to the header with a description:
http://www.spinics.net/lists/linux-pci/msg30941.html
For your convenience, I've also pushed a branch out to github that is 3.15-rc3 + these changes, you'll need to add whatever other patches (i915/acs) on top:
git://github.com/awilliam/linux-vfio.git
branch: dma-alias
Let me know how it goes.
Alex, thank you!
I have specified:source=("git://github.com/awilliam/linux-vfio.git#branch=dma-alias"
in PKGBUILD, I am not sure that is right. Could you please specify how to check that sourced are exactly from dma-alias branch?
I don't use archlinux, so I have no idea what that does. If you have the build tree available to examine, the last patch removes the function named pci_get_dma_source from drivers/pci/quirks.c. If that matches what you find in the tree, you probably have the correct code.
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
Can't apply ACS patch:
src/linux-vfio/drivers/pci/quirks.c.rej
--- drivers/pci/quirks.c 2013-10-19 19:28:15.000000000 +0000
+++ drivers/pci/quirks.c 2013-10-23 18:02:18.000000000 +0000
@@ -3517,6 +3619,7 @@
{ PCI_VENDOR_ID_ATI, 0x439d, pci_quirk_amd_sb_acs },
{ PCI_VENDOR_ID_ATI, 0x4384, pci_quirk_amd_sb_acs },
{ PCI_VENDOR_ID_ATI, 0x4399, pci_quirk_amd_sb_acs },
+ { PCI_ANY_ID, PCI_ANY_ID, pcie_acs_overrides },
{ 0 }
};
Offline
Can't apply ACS patch:
src/linux-vfio/drivers/pci/quirks.c.rej --- drivers/pci/quirks.c 2013-10-19 19:28:15.000000000 +0000 +++ drivers/pci/quirks.c 2013-10-23 18:02:18.000000000 +0000 @@ -3517,6 +3619,7 @@ { PCI_VENDOR_ID_ATI, 0x439d, pci_quirk_amd_sb_acs }, { PCI_VENDOR_ID_ATI, 0x4384, pci_quirk_amd_sb_acs }, { PCI_VENDOR_ID_ATI, 0x4399, pci_quirk_amd_sb_acs }, + { PCI_ANY_ID, PCI_ANY_ID, pcie_acs_overrides }, { 0 } };
Sooo... add it
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
Yes, modified patch to:
/*
* AMD has indicated that the devices below do not support peer-to-peer
* in any system where they are found in the southbridge with an AMD
@@ -3404,6 +3505,7 @@ static int pci_quirk_amd_sb_acs(struct p
#endif
}
+
static const struct pci_dev_acs_enabled {
u16 vendor;
u16 device;
@@ -3415,6 +3517,7 @@ static const struct pci_dev_acs_enabled
{ PCI_VENDOR_ID_ATI, 0x439d, pci_quirk_amd_sb_acs },
{ PCI_VENDOR_ID_ATI, 0x4384, pci_quirk_amd_sb_acs },
{ PCI_VENDOR_ID_ATI, 0x4399, pci_quirk_amd_sb_acs },
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_pch_acs },
+ { PCI_ANY_ID, PCI_ANY_ID, pcie_acs_overrides },
{ 0 }
};
added line
{ PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_intel_pch_acs },
Offline
Strange, but no any changes: still Dmar error.
Offline
Strange, but no any changes: still Dmar error.
Is it the same DMAR error, on device 04:00.0? I've got a new processor coming tomorrow that will let me do VT-d with that bridge, until then I don't really know whether to handle it as a PCIe-to-PCI bridge or a PCI-to-PCI bridge.
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
myweb wrote:Strange, but no any changes: still Dmar error.
Is it the same DMAR error, on device 04:00.0? I've got a new processor coming tomorrow that will let me do VT-d with that bridge, until then I don't really know whether to handle it as a PCIe-to-PCI bridge or a PCI-to-PCI bridge.
Yes, it is the same error:
DMAR:[DMA Write] Request device [04:00.0] fault addr fffff000
DMAR:[fault reason 02] Present bit in context entry is clear
dmar: DRHD: handling fault status reg 2
dmar: DRHD: handling fault status reg 3
Last edited by myweb (2014-05-02 07:54:04)
Offline
aw wrote:myweb wrote:Strange, but no any changes: still Dmar error.
Is it the same DMAR error, on device 04:00.0? I've got a new processor coming tomorrow that will let me do VT-d with that bridge, until then I don't really know whether to handle it as a PCIe-to-PCI bridge or a PCI-to-PCI bridge.
Yes, it is the same error:
DMAR:[DMA Write] Request device [04:00.0] fault addr fffff000 DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 2 dmar: DRHD: handling fault status reg 3
Does this help?
https://github.com/awilliam/linux-vfio/ … b2dc4db04c
I've pushed it to the dma-alias-test branch for you to try.
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
myweb wrote:aw wrote:Is it the same DMAR error, on device 04:00.0? I've got a new processor coming tomorrow that will let me do VT-d with that bridge, until then I don't really know whether to handle it as a PCIe-to-PCI bridge or a PCI-to-PCI bridge.
Yes, it is the same error:
DMAR:[DMA Write] Request device [04:00.0] fault addr fffff000 DMAR:[fault reason 02] Present bit in context entry is clear dmar: DRHD: handling fault status reg 2 dmar: DRHD: handling fault status reg 3
Does this help?
https://github.com/awilliam/linux-vfio/ … b2dc4db04c
I've pushed it to the dma-alias-test branch for you to try.
Thank you!
I will recompile kernel and try.
I will let you know results in hour or two.
Offline
Anybody used vfio with libvirt and virt-manager? I create VM in virt-manager, it starts but in commandline of qemu proccess a can't find "magick" option "-M q35", virt-manager or libvirt not support this or I do something wrong? I need to passthrough my second GPU GTX750Ti to Win8.1 VM, and i've got 43 error now.
P.S. I need virt-manager or something GUI tool because this is for my parents
Last edited by ProFfeSsoRr (2014-05-02 16:16:08)
Offline
Does this help?
https://github.com/awilliam/linux-vfio/ … b2dc4db04c
I've pushed it to the dma-alias-test branch for you to try.
May 02 23:00:46 dhcppc5 kernel: dmar: DMAR:[DMA Write] Request device [04:00.0] fault addr fffff000
DMAR:[fault reason 02] Present bit in context entry is clear
May 02 23:00:46 dhcppc5 kernel: dmar: DRHD: handling fault status reg 3
No, it does not help.
Offline
All,
Let me first take the time to thank you all for the detailed information and patches.
My setup looks like this:
Asus Z87-A
Intel I7 4770
Asus GTX 760
OS:
Vanilla Kernel 3.14.1 + mainline patches (from main post)
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-4)
Guest:
windows 8.1 + latest patches
Nvidia driver 9.18.13.2619
All KVM modules are build into the kernel. No modules are used for KVM.
Boot options:
$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.14.1-kvm root=/dev/mapper/vg00-debian--root ro pci-stub.ids=10de:1187,10de:0e0a intel_iommu=on pcie_acs_override=downstream vfio_iommu_type1.allow_unsafe_interrupts=1 kvm.ignore_msrs=1
Qemu (Still WIP as I'm quite new to KVM, I used to be a XEN user):
qemu-system-x86_64 \
-name Windows-8 \
-cpu host \
-smp 4,sockets=1,cores=2,threads=2 \
-enable-kvm \
-m 4G \
-boot menu=on \
-balloon none \
-serial null \
-parallel null \
-soundhw hda \
-k fr-be \
-machine type=q35,accel=kvm \
-boot order=cd \
-device ahci,id=ahci \
-device virtio-scsi-pci,id=scsi \
-drive id=win8,format=raw,file=/dev/vg00/win8 -device ide-hd,bus=ide.0,drive=win8 \
-drive id=win7,format=raw,file=/dev/vg00/win7-x64 -device ide-hd,bus=ide.1,drive=win7 \
-drive file=/home/brainkiller/Downloads/virtio-win-0.1-74.iso,id=virtiocd -device ide-cd,bus=ide.2,drive=virtiocd \
-net nic,macaddr=00:16:3E:51:20:4C,model=virtio -net tap \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 \
-vga none \
-monitor none \
-display none \
Initially I was blocked but this turned out to solved by upgrading qemu to 2.0.0
Thanks again for all advice, I just wanted to share another success story and to indicate another working setup
Regards,
Brainkiller
Offline
aw wrote:Does this help?
https://github.com/awilliam/linux-vfio/ … b2dc4db04c
I've pushed it to the dma-alias-test branch for you to try.
May 02 23:00:46 dhcppc5 kernel: dmar: DMAR:[DMA Write] Request device [04:00.0] fault addr fffff000 DMAR:[fault reason 02] Present bit in context entry is clear May 02 23:00:46 dhcppc5 kernel: dmar: DRHD: handling fault status reg 3
No, it does not help.
Hmm, I got my VT-d CPU installed in the system with same bridge and can confirm that the patch in the dma-alias-test branch is definitely needed for the ASM1083 bridge. Without it, a conventional PCI NIC installed in the system streams IOMMU faults. So, I'm not sure what's happening. The fault address you're getting does look suspicious, being exactly the last page before the 32bit, 4G barrier. Is that the only fault address you get? There are devices out there that are incompatible with IOMMUs, either the driver doesn't use the DMA API correctly or the hardware makes stray accesses. Sometimes the only solution for those devices is to run the system with iommu=pt to put them into passthrough mode.
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
myweb wrote:aw wrote:Does this help?
https://github.com/awilliam/linux-vfio/ … b2dc4db04c
I've pushed it to the dma-alias-test branch for you to try.
May 02 23:00:46 dhcppc5 kernel: dmar: DMAR:[DMA Write] Request device [04:00.0] fault addr fffff000 DMAR:[fault reason 02] Present bit in context entry is clear May 02 23:00:46 dhcppc5 kernel: dmar: DRHD: handling fault status reg 3
No, it does not help.
Hmm, I got my VT-d CPU installed in the system with same bridge and can confirm that the patch in the dma-alias-test branch is definitely needed for the ASM1083 bridge. Without it, a conventional PCI NIC installed in the system streams IOMMU faults. So, I'm not sure what's happening. The fault address you're getting does look suspicious, being exactly the last page before the 32bit, 4G barrier. Is that the only fault address you get? There are devices out there that are incompatible with IOMMUs, either the driver doesn't use the DMA API correctly or the hardware makes stray accesses. Sometimes the only solution for those devices is to run the system with iommu=pt to put them into passthrough mode.
I am terribly sorry, I used old branch dma-alias instead of dma-alias-test.
I compiled a dma-alias-test and my DVB card works in host system (I can't check in VM since I have trouble to boot it)
But I experience some issue with USB controller (00:1a.0)
dmar: DRHD: handling fault status reg 3
DMAR:[DMA Read] Request device [00:1a.0] fault addr ee000
DMAR:[fault reason 06] PTE Read access is not set
dmar: DRHD: handling fault status reg 3
dmar: DMAR:[DMA Read] Request device [00:1a.0] fault addr ee000
DMAR:[fault reason 06] PTE Read access is not set
Offline
Anybody used vfio with libvirt and virt-manager? I create VM in virt-manager, it starts but in commandline of qemu proccess a can't find "magick" option "-M q35", virt-manager or libvirt not support this or I do something wrong? I need to passthrough my second GPU GTX750Ti to Win8.1 VM, and i've got 43 error now.
P.S. I need virt-manager or something GUI tool because this is for my parents
I just got it working the other day, it's actually quite simple.
Set up libvirt as you normally would and remove the display server/display driver.
Then do a virsh edit, alter the first line to look like this
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
and then add a pci device like you would with regular qemu
<qemu:commandline>
<qemu:arg value='-device'/>
<qemu:arg value='ioh3420,bus=pci.0,addr=1c.0,multifunction=on,port=1,chassis
=1,id=root.1'/>
<qemu:arg value='-device'/>
<qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on
,x-vga=on>
<qemu:arg value='-device'/>
<qemu:arg value='vfio-pci,host=01:00.1,bus=root.1,addr=00.1'/>
</qemu:commandline>
</domain>
Last edited by Sphaerophoria (2014-05-03 01:53:07)
Offline
aw wrote:myweb wrote:May 02 23:00:46 dhcppc5 kernel: dmar: DMAR:[DMA Write] Request device [04:00.0] fault addr fffff000 DMAR:[fault reason 02] Present bit in context entry is clear May 02 23:00:46 dhcppc5 kernel: dmar: DRHD: handling fault status reg 3
No, it does not help.
Hmm, I got my VT-d CPU installed in the system with same bridge and can confirm that the patch in the dma-alias-test branch is definitely needed for the ASM1083 bridge. Without it, a conventional PCI NIC installed in the system streams IOMMU faults. So, I'm not sure what's happening. The fault address you're getting does look suspicious, being exactly the last page before the 32bit, 4G barrier. Is that the only fault address you get? There are devices out there that are incompatible with IOMMUs, either the driver doesn't use the DMA API correctly or the hardware makes stray accesses. Sometimes the only solution for those devices is to run the system with iommu=pt to put them into passthrough mode.
I am terribly sorry, I used old branch dma-alias instead of dma-alias-test.
I compiled a dma-alias-test and my DVB card works in host system (I can't check in VM since I have trouble to boot it)But I experience some issue with USB controller (00:1a.0)
dmar: DRHD: handling fault status reg 3 DMAR:[DMA Read] Request device [00:1a.0] fault addr ee000 DMAR:[fault reason 06] PTE Read access is not set dmar: DRHD: handling fault status reg 3 dmar: DMAR:[DMA Read] Request device [00:1a.0] fault addr ee000 DMAR:[fault reason 06] PTE Read access is not set
These patches should not have changed anything with respect to this device.
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
Could you please help to fix:
sudo virsh -c qemu:///system start X
error: Failed to start domain X
error: internal error: early end of file from monitor: possible problem:
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio_dma_map(0x7fe2de4e6f70, 0x0, 0x80000000, 0x7fe1c4000000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio_dma_map(0x7fe2de4e6f70, 0x100000000, 0x80000000, 0x7fe244000000) = -12 (Cannot allocate memory)
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: memory listener initialization failed for container
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to setup container for group 13
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 13
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
Dmesg
[ 3684.367018] vfio_pin_pages: RLIMIT_MEMLOCK (65536) exceeded
[ 3684.367036] vfio_pin_pages: RLIMIT_MEMLOCK (65536) exceeded
[ 3684.367362] vfio_pin_pages: RLIMIT_MEMLOCK (65536) exceeded
[ 3684.367377] vfio_pin_pages: RLIMIT_MEMLOCK (65536) exceeded
VM XML:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<name>X</name>
<uuid>9efa8a71-b193-c50b-c770-9ce6dad02390</uuid>
<memory unit='KiB'>4194304</memory>
<currentMemory unit='KiB'>4194304</currentMemory>
<vcpu placement='static'>2</vcpu>
<os>
<type arch='x86_64' machine='pc-q35-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/sbin/qemu-system-x86_64</emulator>
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/dev/md1'/>
<target dev='sda' bus='sata'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
</controller>
<controller type='pci' index='0' model='pcie-root'/>
<controller type='pci' index='1' model='dmi-to-pci-bridge'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/>
</controller>
<controller type='pci' index='2' model='pci-bridge'>
<address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/>
</controller>
<controller type='ide' index='0'/>
<interface type='bridge'>
<mac address='52:54:00:4b:be:6d'/>
<source bridge='br0'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/>
</interface>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x02' slot='0x05' function='0x0'/>
</memballoon>
</devices>
<qemu:commandline>
<qemu:arg value='-device'/>
<qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1'/>
<qemu:arg value='-device'/>
<qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/>
<qemu:arg value='-device'/>
<qemu:arg value='vfio-pci,host=01:00.1,bus=root.1,addr=00.1'/>
<qemu:arg value='-device'/>
<qemu:arg value='vfio-pci,host=00:1a.0,bus=root.1'/>
<qemu:arg value='-device'/>
<qemu:arg value='vfio-pci,host=00:1b.0,bus=root.1'/>
</qemu:commandline>
</domain>
It would be nice to use <hostdev type='pci' managed='yes'> <driver name='vfio'/> since I use libvirt git, but it is unclear how to set "x-vga=on".
Last edited by myweb (2014-05-03 09:50:34)
Offline
I'm totally new about KVM, I read in the first post in the requirements: "At least 2 GPU's, one primary boot device and the card you wish to pass-through."
If I have an intel cpu (i7 3770) with an iGPU and a nvidia card (GTX 780) , I have to physically connect the monitor to the iGPU?
In that way I can't use the nvidia card in linux (for example for native gaming), am I missing something?
Last edited by easd (2014-05-03 10:00:31)
Offline
I have managed to pass through my GeForce GTX 770M into KVM.
The GPU showed Error 10 for the very beginning and after I have installed latest ForceWare drivers, it showed error 43.
However if i disable and re-enable the card in Device Manager it showed that the device is working correctly.
Unfortunately as a second device and I was unable to boot Windows with nvidia card set as primary due to error 43, which i come across every time i reboot the VM.
All the time i need to disable and re-enable the dGPU in order to make Windows marking it as working.
I am not sure if this is connected with nVidia Optimus, or just GTX 770M. I have found that some of you managed to get GF 7xx working, while others not.
Also there is no such problem with ATI cards. Due to that i think that more people having notebooks should give it a try, especially with older GeForce cards and with mobile ATI cards.
As the prove I want to show you a screenshot:
Last edited by belliash (2014-05-04 13:47:55)
Offline
I have managed to pass through my GeForce GTX 770M into KVM.
The GPU showed Error 10 for the very beginning and after I have installed latest ForceWare drivers, it showed error 43.
However if i disable and re-enable the card in Device Manager it showed that the device is working correctly.
Unfortunately as a second device and I was unable to boot Windows with nvidia card set as primary due to error 43, which i come across every time i reboot the VM.
All the time i need to disable and re-enable the dGPU in order to make Windows marking it as working.I am not sure if this is connected with nVidia Optimus, or just GTX 770M. I have found that some of you managed to get GF 7xx working, while others not.
Also there is no such problem with ATI cards. Due to that i think that more people having notebooks should give it a try, especially with older GeForce cards and with mobile ATI cards.As the prove I want to show you a screenshot:
Thumbnail and stuff… https://wiki.archlinux.org/index.php/Fo … s_and_Code
i'm sorry for my poor english wirting skills…
Offline
I'm trying to get this working on a Ubuntu 14.04 system, host on onboard 4770 intel graphics, guest on a 7870. I grabbed kernel 3.14.1 mainline from the kernel PPA but I'm still getting the host "taste the rainbow" color change when I try to boot the test guest. I take it the intel vga fix isn't yet upstreamed? Or is it in 3.15rcX and I should try one of the RC kernels?
Offline
I'm trying to get this working on a Ubuntu 14.04 system, host on onboard 4770 intel graphics, guest on a 7870. I grabbed kernel 3.14.1 mainline from the kernel PPA but I'm still getting the host "taste the rainbow" color change when I try to boot the test guest. I take it the intel vga fix isn't yet upstreamed? Or is it in 3.15rcX and I should try one of the RC kernels?
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
That was it, thanks aw. Can you link that off your first post? (or is it and I just missed it? I read the first post a couple times)
Maybe I'll go back to the secondary vga as you referenced there. That's how I'm operating now, my only problem with 14.04 (and 13.10) was that my current config (non-vfio style) didn't work anymore.
Last edited by svirpridon (2014-05-05 02:41:41)
Offline