You are not logged in.
Also thinking about trying pci-assign to see if it works.
It won't. It's kinda deprecated.
Device code 12, afair, is "not enough resources for a device to run". Since qemu says "BAR 3 MMAP unsupported" - it is not able to mmap BAR 3 - some(BAR 3 that is) region of memory is in use. Check lspci (with numerous -v and -n options) output for memory ranges, then check /proc/iomem and /proc/mtrr. Maybe you'll notice that your GPU is in use by something like vesa or nouveau, maybe you'll need to enable MTRR cleanup via kernel parameters. And what host GPU do you have?
Also you may be running into nvidia driver related problems - ensure that is not the case by disabling hyper-v extensions(or whatever it was) and hide kvm signature.
...aand you might not be needing that -bios line at all.
Last edited by Duelist (2014-10-28 09:50:16)
The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.
Offline
My success story:
ASRock FM2A88M Extreme4+ [UEFI BIOS 2.40]
AMD A10-6700 with Radeon HD 8670D
AMD Radeon HD 7870 [Gigabyte GV-R787OC-2GD - UEFI BIOS F11]
gentoo-sources-3.17.1 kernel without any patches for VGA-Passthrough
qemu-2.1.50
OVMF 16056-1 from ovmf-svn
Windows 8.1 with Catalyst driver v.14.9
host: HD 8670D
guest: HD 7870
vfio-assign did not work for me (crash during radeon driver installation. with CCC or not, through setup.exe or Device Manager, seabios or UEFI-ovfm, with romfile or without), so I use good old pci-assign which works perfectly.
pci-stub in kernel cmdline with fix for ASRock FM2A88M Extreme4+ :
iommu=pt ivrs_ioapic[5]=00:14.0 pci-stub.ids=1002:6818,1002:aab0Install:
qemu-system-x86_64 -enable-kvm -m 4096 -cpu host -smp 4,sockets=1,cores=4,threads=1 \
-vga qxl -rtc base=localtime -pflash ovmf_x64.bin \
-device pci-assign,host=01:00.0 -device pci-assign,host=01:00.1 \
-device virtio-scsi-pci,id=scsi -drive file=windows8.img,if=virtio,id=disk_primary,format=raw \
-drive file=windows8.iso,id=iso_install,if=none -device scsi-cd,drive=iso_install \
-cdrom virtio-win-0.1-81.isoRun:
qemu-system-x86_64 -enable-kvm -m 4096 \
-cpu host,hv_relaxed,hv_vapic,hv_spinlocks=0x1000 -smp 4,sockets=1,cores=4,threads=1 \
-vga none -rtc base=localtime -pflash ovmf_x64.bin \
-device pci-assign,host=01:00.0 \
-device virtio-scsi-pci,id=scsi -drive file=windows8.img,if=virtio,id=disk_primary,format=rawLuxMark (OpenCL) benchmark results: LuxBall HDR - Only selected devices (GPU Pitcairn):
Win8.1 native: 10730
Linux qemu-kvm vga-passthrough: 9208
Difference: 14%
Not bad? Or what?
Last edited by gyrfalco (2014-10-28 10:40:20)
Offline
My success story:
ASRock FM2A88M Extreme4+ [UEFI BIOS 2.40]
AMD A10-6700 with Radeon HD 8670D
AMD Radeon HD 7870 [Gigabyte GV-R787OC-2GD - UEFI BIOS F11]
gentoo-sources-3.17.1 kernel without any patches for VGA-Passthrough
qemu-2.1.50
OVMF 16056-1 from ovmf-svn
Windows 8.1 with Catalyst driver v.14.9
host: HD 8670D
guest: HD 7870vfio-assign did not work for me (crash during radeon driver installation. with CCC or not, through setup.exe or Device Manager, seabios or UEFI-ovfm, with romfile or without), so I use good old pci-assign which works perfectly.
pci-stub in kernel cmdline with fix for ASRock FM2A88M Extreme4+ :
iommu=pt ivrs_ioapic[5]=00:14.0 pci-stub.ids=1002:6818,1002:aab0Install:
qemu-system-x86_64 -enable-kvm -m 4096 -cpu host -smp 4,sockets=1,cores=4,threads=1 \ -vga qxl -rtc base=localtime -pflash ovmf_x64.bin \ -device pci-assign,host=01:00.0 -device pci-assign,host=01:00.1 \ -device virtio-scsi-pci,id=scsi -drive file=windows8.img,if=virtio,id=disk_primary,format=raw \ -drive file=windows8.iso,id=iso_install,if=none -device scsi-cd,drive=iso_install \ -cdrom virtio-win-0.1-81.isoRun:
qemu-system-x86_64 -enable-kvm -m 4096 \ -cpu host,hv_relaxed,hv_vapic,hv_spinlocks=0x1000 -smp 4,sockets=1,cores=4,threads=1 \ -vga none -rtc base=localtime -pflash ovmf_x64.bin \ -device pci-assign,host=01:00.0 \ -device virtio-scsi-pci,id=scsi -drive file=windows8.img,if=virtio,id=disk_primary,format=rawLuxMark (OpenCL) benchmark results: LuxBall HDR - Only selected devices (GPU Pitcairn):
Win8.1 native: 10730
Linux qemu-kvm vga-passthrough: 9208Difference: 14%
Not bad? Or what?
Surprising! But you've used OVMF anyway. I think AW will tell us some difference. I thought that pci-assign was deprecated..
The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.
Offline
Surprising! But you've used OVMF anyway. I think AW will tell us some difference. I thought that pci-assign was deprecated..
Not really surprising with OVMF, Radeon cards don't require any quirks when running with EFI. Legacy KVM device assignment is deprecated though, so it will eventually be removed. I'd certainly rather fix vfio if it's somehow getting in the way than endorse a solution using pci-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
Sadly I'm still having problems with the passthrough. I found an issue where vesafb was caused the bar 3 error (my fault. messed up with card was primary in the bios). Thank Duelist for the suggestions, helped a lot.
I updated to qemu 2.1.2 and now my script looks like
sudo qemu-system-x86_64 -enable-kvm -M q35 -m 4096 -cpu host,kvm=off \
-smp 4,sockets=1,cores=4,threads=1 \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=03:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=03:00.1,bus=root.1,addr=00.1 \
-usb -usbdevice host:046d:c52b \
-drive file=/home/server/windowstry.img,id=disk,format=raw -device ide-hd,bus=ide.0,drive=disk \
-drive file=/home/server/Downloads/Win.iso,id=isocd -device ide-cd,bus=ide.1,drive=isocd \
-boot menu=onI am still having a code 12 error as far as I can tell and the GPU is refusing to output anything out the back of it. My image got stuck in a repair loop so I'll see if the error has changed afterward.
Offline
I am not sure with OVMF, but maybe add -vga none, to get rid of error code 12?
Offline
Well, looks like I didn't save my edit...
Anyway with vga none, I am getting no output from the 750 and after ~ 30 seconds I get a kvm internal error.
Can't post the full message as I am using my phone but the cs of the message seemed to correspond to the cards memory listed in cat /proc/iomem
My mate passed a quadro through at the same time using similar hardware and following my steps. (the update was to solve his code 43 error). Do I need to get the cards rom and specify it?
Offline
You need to check aw's vfio blog, about uefi rom, maybe you need rom file or/and your gpu doesn't have uefi rom?
Again not sure, my gigabyte gtx680 4gb works either way (without rom file option), I'm using old vga way with patches, since I have 0 problems with it.
Last edited by slis (2014-10-29 11:09:23)
Offline
What patches are you running? I am running none (although a lot of fixes) cause I don't have an igpu to worry about. I'm still trying the vga way for now, just started looking at ovmf recently but am considering just putting the old way aside for now and trying it.
Last edited by Casperian (2014-10-29 11:53:24)
Offline
I am not sure with OVMF, but maybe add -vga none, to get rid of error code 12?
Are you sure he is using OVMF? His commandline "script" doesn't do anything related. Some time ago there was even explicitly qemu's bios via -bios option.
If he's fine without OVMF - let it be. Because UEFI is tricky.
The UEFI trickiness:
1.My GPUs still have old VGA bios inside. I have a new, hybrid VGA-UEFI bios, but i'm unable to flash it hardware-wise and it appear to cause hangups on my qemu machine when using -romfile option. YMMV, but better be safe.
2.Windows. "We explicitly do not want CSM". I am not sure if you don't need to reinstall windows in order to get it working under UEFI if there was BIOS during the installation process. I guess there may be some details related to the bootloader.
When using vfio x-vga=on, you HAVE TO -vga none. Only that way you're getting output of you GPU.
When you are debugging something, like, uninstalling drivers, you can -vga std/qxl BUT YOU HAVE TO x-vga=off.
Last edited by Duelist (2014-10-29 12:38:58)
The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.
Offline
I use acs_override and i915 patch with 3.15 kernel.
edit:
yeah i just saw that he isn't using omvf...
unrelated (my question):
when u specify <qemu:arg value='if=pflash,format=raw,readonly,file=/root/OVMF-pure-efi.fd'/> in xml.
Does that mean that i am 100% using efi, or?
Last edited by slis (2014-10-29 12:44:23)
Offline
unrelated (my question):
when u specify <qemu:arg value='if=pflash,format=raw,readonly,file=/root/OVMF-pure-efi.fd'/> in xml.
Does that mean that i am 100% using efi, or?
You will also have to connect OVMF-VARS.
Check
http://awilliam.github.io/presentations … 2014/#/4/2
this slide from alex's presentation for exact example of using OVMF split image with libvirt.
Last edited by Duelist (2014-10-29 14:38:11)
The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.
Offline
slis wrote:I am not sure with OVMF, but maybe add -vga none, to get rid of error code 12?
Are you sure he is using OVMF? His commandline "script" doesn't do anything related. Some time ago there was even explicitly qemu's bios via -bios option.
If he's fine without OVMF - let it be. Because UEFI is tricky.The UEFI trickiness:
1.My GPUs still have old VGA bios inside. I have a new, hybrid VGA-UEFI bios, but i'm unable to flash it hardware-wise and it appear to cause hangups on my qemu machine when using -romfile option. YMMV, but better be safe.
2.Windows. "We explicitly do not want CSM". I am not sure if you don't need to reinstall windows in order to get it working under UEFI if there was BIOS during the installation process. I guess there may be some details related to the bootloader.When using vfio x-vga=on, you HAVE TO -vga none. Only that way you're getting output of you GPU.
When you are debugging something, like, uninstalling drivers, you can -vga std/qxl BUT YOU HAVE TO x-vga=off.
I would certainly NOT expect that you can move a BIOS guest image to EFI without doing a re-install. These are fundamentally different boot interfaces for the guest.
Casperian, why are you using Q35? Try 440FX. EDIT: and if you get no VGA output, VGA arbitration is probably an issue. Check the FAQ in the link below.
Last edited by aw (2014-10-29 14:42:35)
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
The video for my talk is up: https://www.youtube.com/watch?v=NhZ9eIpg2nM
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
For 3.18 what options do you guys select in kernel config to get virtual networks to work in libvirt?
Offline
hi there! this thread is much appreciated. I am trying to passthrough my MSI GTX 980 Gaming to Windows 8.1. I followed this guide, but I get a Code 43 error. Then I found this: http://vfio.blogspot.de/2014/08/vfiovga-faq.html
In there this is stated:
Question 10:
I'm assigning an Nvidia card to a Windows guest and get a Code 43 error in device manager.
Answer:
The Nvidia driver, starting with 337.88 identifies the hypervisor and disables the driver when KVM is found. Nvidia claims this is an unintentional bug, but has no plans to fix it. To work around the problem, we can hide the hypervisor by adding kvm=off to the list of cpu options provided (QEMU 2.1+ required). libvirt support for this option is currently upstream.
Note that -cpu kvm=off is not a valid incantation of the cpu parameter, a CPU model such as host, or SandyBridge must also be provided, ex: -cpu host,kvm=off.
Update: The above workaround is sufficient for drivers 337.88 and 340.52. With 344.11 and presumably later, the Hyper-V CPUID extensions supported by KVM also trigger the Code 43 error. Disabling these extensions appears to be sufficient to allow the 344.11 driver to work. This includes all of the hv_* options to -cpu. In libvirt, this includes:
<hyperv>
<relaxed state='on'/>
<vapic state='on'/>
<spinlocks state='on' retries='8191'/></hyperv>
and
<clock offset='localtime'>
<timer name='hypervclock' present='yes'/>
</clock>
Unfortunately removing these options will impose a performance penalty as these paravirtual interfaces are designed to improve the efficiency of virtual machines.
Now: I don't even have libvirt installed. Do I need it for Nvidia passthrough? Thanks a lot for any help! I am really excited about this project.
Offline
Now: I don't even have libvirt installed. Do I need it for Nvidia passthrough? Thanks a lot for any help! I am really excited about this project.
No, libvirt is not required, it's provided as an example, but don't forget to notice the comment about removing all the hv_* options from the -cpu parameter. Try with just "-cpu host,kvm=off" (and make sure you're running a new enough QEMU to support the kvm=off option, QEMU 2.1 or newer). If you're using OVMF then you need to be using qemu.git to have the Nvidia quirk turned on without x-vga=on (it will be in QEMU 2.2)
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
thank you very much Alex! I am using qemu-git-2.2.r35796.gff0d487-1 I hope that's the right one. On my test Setup, I have no LVM, no GPT and no UEFI and I also use "-cpu-host,kvm=off", but I still have that error. This is how I start Windows 8.1:
qemu-system-x86_64 -enable-kvm -M q35 -m 8G -cpu host,kvm=off \
-smp 6,sockets=1,cores=6,threads=1 \
-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 \
-drive file=/root/windows.img,id=disk,format=raw \
-cdrom /root/windows.iso \
-usb -usbdevice host:046d:c312
is there an obvious mistake?
Offline
I am using Q35 because my end goal is to have a linux based VM with access to cuda enabled GPU. Just doing it with windows for now though.
Been looking into VGA arbitration and yeah... seems like that is my problems.
Offline
thank you very much Alex! I am using qemu-git-2.2.r35796.gff0d487-1 I hope that's the right one. On my test Setup, I have no LVM, no GPT and no UEFI and I also use "-cpu-host,kvm=off", but I still have that error. This is how I start Windows 8.1:
qemu-system-x86_64 -enable-kvm -M q35 -m 8G -cpu host,kvm=off \
-smp 6,sockets=1,cores=6,threads=1 \
-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 \
-drive file=/root/windows.img,id=disk,format=raw \
-cdrom /root/windows.iso \
-usb -usbdevice host:046d:c312is there an obvious mistake?
You don't seem to have -vga none, unless I am blind which is possible
Offline
thank you very much Alex! I am using qemu-git-2.2.r35796.gff0d487-1 I hope that's the right one. On my test Setup, I have no LVM, no GPT and no UEFI and I also use "-cpu-host,kvm=off", but I still have that error. This is how I start Windows 8.1:
qemu-system-x86_64 -enable-kvm -M q35 -m 8G -cpu host,kvm=off \
-smp 6,sockets=1,cores=6,threads=1 \
-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 \
-drive file=/root/windows.img,id=disk,format=raw \
-cdrom /root/windows.iso \
-usb -usbdevice host:046d:c312is there an obvious mistake?
If you're using VGA then you may need host kernel patches for the VGA arbiter to work correctly. You're also missing "-vga none". (And I keep dis-recommending Q35, it's not needed for Windows guests)
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
slis wrote:unrelated (my question):
when u specify <qemu:arg value='if=pflash,format=raw,readonly,file=/root/OVMF-pure-efi.fd'/> in xml.
Does that mean that i am 100% using efi, or?
You will also have to connect OVMF-VARS.
Check
http://awilliam.github.io/presentations … 2014/#/4/2
this slide from alex's presentation for exact example of using OVMF split image with libvirt.
I just checked my win8 vm, i just added OVMF-pure-efi.fd, then selected boot device from "bios"/installed win8, and windows says that it's using UEFI, are OVMF-VARS needed/built? Or they are generated?
thx
Offline
I just checked my win8 vm, i just added OVMF-pure-efi.fd, then selected boot device from "bios"/installed win8, and windows says that it's using UEFI, are OVMF-VARS needed/built? Or they are generated?
If your OVMF-pure-efi.fd is exactly 2MB, then it's a unified image that contains the code alongside the variable storage in the same image. In this case each VM should have a writable copy of the image. This works, but makes it difficult to upgrade the UEFI image and retain the variables. Fortunately you likely don't care about the variables and the win8 bootloader seems to automatically regenerate them on every boot.
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
Got it, thx for explanation.
Offline
And I keep dis-recommending Q35, it's not needed for Windows guests
Can you write a somewhat detailed answer about the reason why Q35 is bad? Or is it covered in your speech(which i haven't watched yet)?
EDIT:Now i've watched your speech, and it doesn't solves the puzzle for me.
Okay, 440FX is just older, and it's more bug-free and stable. Is that the only reason to favor it over Q35?
Last edited by Duelist (2014-10-30 15:09:51)
The forum rules prohibit requesting support for distributions other than arch.
I gave up. It was too late.
What I was trying to do.
The reference about VFIO and KVM VGA passthrough.
Offline