You are not logged in.
Intel i5 2500 @ 3300 Mhz
This is not a processor version, it's a family and a speed, so we have no idea if your CPU supports VT-d. Look it up on ark.intel.com
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
sl44x wrote:Intel i5 2500 @ 3300 Mhz
This is not a processor version, it's a family and a speed, so we have no idea if your CPU supports VT-d. Look it up on ark.intel.com
Sorry. Here the full description of this processor:
http://ark.intel.com/products/52209/Int … o-3_70-GHz
Intel® Virtualization Technology for Directed I/O (VT-d) ‡ YesThe processor has support VT-d. I belive that is the bios or chipset of the mobo that not.
Last edited by sl44x (2015-02-18 01:06:32)
Offline
This is the error in dmesg when I try to assign the sound card alone or both the controller and the card:
genirq: Flags mismatch irq 16. 00000080 (vfio-intx(0000:00:1a.0)) vs. 00000000 (vfio-intx(0000:08:04.0))And here is the relevant lspci output (the sound card is behind a bridge, which I don't assign):
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: Gigabyte Technology Co., Ltd 7 Series/C210 Series Chipset Family USB Enhanced Host Controller 07:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04) (prog-if 00 [Normal decode]) 08:04.0 Multimedia audio controller: C-Media Electronics Inc CMI8788 [Oxygen HD Audio] Subsystem: ASUSTeK Computer Inc. CMI8788 [Oxygen HD Audio]
I had similar issues with my Xonar DX, and found two ways to possibly fix the issue: either move the card to another slot, or go into the BIOS and disable the conflicting EHCI controller (while leaving the other enabled).
I can imagine some BIOSes having EHCI #1 and #2 swapped, so you should double-check it once you reboot.
Note that the Xonar DX is just a Xonar D1 behind a PLX PEX8112, and StarTech offers a standalone PEX8112 board for use with any arbitrary PCI card.
Offline
Something OVMF/UEFI-Rom related:
I just investigated why I don't see the tiancore bootscreen anymore after switching from my 750Ti to an R9 280X. Turns out it has only a legacy rom, but apart from the inability to see the UEFI output of the VM at boot it works fine!? Could this work for all cards or only AMD because the card isn't initialized as the primary one?
Edit: If this works with more cards, than we could use older cards with OVMF by installing Windows with a virtual graphics adapter and later switching to the real one, booting, letting Windows install drivers and ready is the legacy-ovmf-hybrid.
Regarding my 280X, I'm gonna flash an other BIOS because there's one rather similar to mine including UEFI support. Thanks again for the rom-parser!
Last edited by mauorrizze (2015-02-18 09:13:01)
Offline
I had similar issues with my Xonar DX, and found two ways to possibly fix the issue: either move the card to another slot,
Not possible. This motherboard just refuses to boot when I move the sound card to another slot.
or go into the BIOS and disable the conflicting EHCI controller (while leaving the other enabled).
Also not possible. There is only one option in UEFI to disable both EHCI controllers. If I disable them, even xHCI stops working pre-boot, so no keyboard/mouse input possible until Linux. In any case, this method isn't better than soft-remove. With soft-remove I can at least use the controller until I choose to disable it.
Note that the Xonar DX is just a Xonar D1 behind a PLX PEX8112
I know there are certain Xonar DX with PLX chip, but mine uses ASMedia as seen in the lspci output.
Offline
Hello guys,
I am also hijacking this thread, thanks to the tutorial in first page, my vga passthrough is not far from working but I'm stuck at the "code 43" phase.
My config:
Cpu: Core I7 860 (first gen with no IGP, but with VT-D)
Motherboard: Asus P7P55D
Graphic card #1 in the first PCI-E 16X port: ATI/AMD Radeon HD4350 fanless for host display
Graphic card #2 in the 2nd PCI-E 16X port: Gainward Golden Sample Geforce 560ti 1Gb for vga passthrough
Host Software config: Archlinux, multiple kernel config, 3.18.5 patch + vga arbiter patch + acs override patch, or 3.18.6 not patched, stock QEMU from Archlinux
Guest soft: Windows 8.1 x64
The VGA passthrough is working fine, when I am launching QEMU, I do see the bios output on the 2nd screen and I can also just install and use Win 8.1 just fine. The only problem I have is that guest reboot is not working and I can only launch QEMU once, if I need to halt the guest, I have to reboot the host to reuse the guest again.
So, after installing Geforce Drivers in the guest, the card is recognized by Windows as GeForce 560ti but I have an "code 43" error like a lot people...
What I tried to solve the problem:
- installing 331 and 335 Geforce drivers version -> same problem
- using microsoft whql drivers -> same problem
- using -cpu host,kvm=off option -> same problem
- Tried with the 3.18.5 patched kernel (i915 + acs override) -> same problem
- fresh 3.18.6 kernel -> same problem
- using 440FX chipset instead of Q35 with the Qemu config: -> same problem
- tried with romfile corresponding to my model -> same problem
Here is my QEMU command:
qemu-system-x86_64 -enable-kvm -M q35 -m 4096 -cpu host,kvm=off -vga none \
-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=06:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=06:00.1,bus=root.1,addr=00.1 \
-drive file=windows.img,id=disk,format=raw,if=none -device ide-hd,bus=ide.0,drive=disk \
-usb -device usb-host,hostbus=1,hostaddr=4 \
-usb -device usb-host,hostbus=1,hostaddr=3I'm stuck and I don't see what is wrong... Ideas or advices would be appreciated :-)
Thank you !
Offline
The only problem I have is that guest reboot is not working and I can only launch QEMU once, if I need to halt the guest, I have to reboot the host to reuse the guest again.
I had the same problem with a card which turned out not to support GPU pass through.
Offline
As a followup to my earlier posts, I've been playing with the various hv* options but unfortunately still haven't had any luck. I always get the "code 43" error in the device manager for the nvidia GPU and the vfio_pci_read_config and vfio_pci_write_config "bad address" errors.
I've tried every version of the nvidia drivers that supports the GTX 970 with no luck, 344.11 being the oldest.
My current qemu invocation is this:
#!/bin/bash
VFIO_DEVS="01:00.0 01:00.1"
sudo /opt/bin/vfio-bind ${VFIO_DEVS}
NAME="Windows 8.1 Enterprise"
MEM=8192
CORES=4
DRIVE=/home/jaeger/VMs/win81/win81.img
CDROM=/home/jaeger/VMs/win81/win81entx64.iso
VIRTIO=/home/jaeger/VMs/win81/virtio-win-0.1-81.iso
OVMF=/home/jaeger/ovmf-x64
sudo QEMU_AUDIO_DRV=pa \
/usr/bin/qemu-system-x86_64 \
-name "${NAME}" \
-nographic \
-enable-kvm \
-cpu host,kvm=off,hv-time=off,hv-vapic=off,hv-relaxed=off \
-m ${MEM} \
-smp cores=${CORES},threads=1,sockets=1 \
-vga none \
-nodefconfig \
-drive if=pflash,format=raw,readonly,file=${OVMF}/OVMF_CODE-pure-efi.fd \
-drive if=pflash,format=raw,file=${OVMF}/OVMF_VARS-pure-efi.fd \
-device vfio-pci,host=01:00.0,multifunction=on \
-device vfio-pci,host=01:00.1 \
-drive file="${DRIVE}",format=raw,id=disk0,if=virtio \
-drive file="${CDROM}",format=raw,id=cd0,if=none \
-device ide-cd,drive=cd0 \
-drive file="${VIRTIO}",format=raw,id=cd1,if=none \
-device ide-cd,drive=cd1 \
-netdev bridge,id=net0 \
-device virtio-net-pci,netdev=net0 \
-soundhw hda \
-usbdevice host:046d:c52b \
-usbdevice host:03f0:0024Has anyone else seen the vfio_pci_read_config and vfio_pci_write_config errors?
Offline
Hello,
thanks to this thread and the great tutorial my setup is also up and works like expected.
Setup:
Asrock Extreme6
I7-4790K
HD4850
Just the power consumption of the second card after shutting down the guest is a problem.
41W without HD4850, linux idle
61W with installed HD4850, linux idle
83W Guest Windows7 idle, linux idle
83W after Guest Windows7 is shut down, linux idle.
After digging around in sysfs and ASPM and googling around, i have absolutly no idea how set the second card in back in idle state.
Maybe someone with more experience have a solution to this problem.
Thank you in advance.
Last edited by Schlunze (2015-02-18 16:37:43)
Offline
Hello guys,
I am also hijacking this thread, thanks to the tutorial in first page, my vga passthrough is not far from working but I'm stuck at the "code 43" phase.
[...]
Here is my QEMU command:
qemu-system-x86_64 -enable-kvm -M q35 -m 4096 -cpu host,kvm=off -vga none \ -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=06:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \ -device vfio-pci,host=06:00.1,bus=root.1,addr=00.1 \ -drive file=windows.img,id=disk,format=raw,if=none -device ide-hd,bus=ide.0,drive=disk \ -usb -device usb-host,hostbus=1,hostaddr=4 \ -usb -device usb-host,hostbus=1,hostaddr=3I'm stuck and I don't see what is wrong... Ideas or advices would be appreciated :-)
Thank you !
Try loading your card from a ROM file (see bottom of post #1). I got mine from
http://www.techpowerup.com/vgabios/I had a lot of trouble with my 560ti within the VM regarding drivers, sleep functions, resets...right now I have it assigned to the host. I use a 6800 series ATI for the VM and it behaves, updates clean.
Offline
Hello everyone. Thank you all for this guide. I have been able to pass through an Nvidia 970 card to Windows 8.1 and had it working. Briefly... Then the driver detected the virtualization and threw up Code 43.
The problem seems to be that I am not booting with OVMF even though I try to. When I point directly to the TianoCore firmware, the ISO is not detected as bootable:
-drive if=pflash,format=raw,readonly,file=/mnt/vault/qemu/ovmf/20150218/OVMF_CODE-pure-efi.fd
-drive if=pflash,format=raw,file=/mnt/vault/qemu/ovmf/20150218/OVMF_VARS-pure-efi.fdI first suspected that I was missing other component such as ipxe.git, etc, due to dangling symlinks in the 20150218 directory and installed those as well. But it doesn't help. When I point to the entire 20150218 directory (which contains a symlink bios.bin -> OVMF-pure-efi.fd), QEMU boots with SeaBios instead:
-L /mnt/vault/qemu/ovmf/20150218Any idea what I might be doing wrong? There are guides on the net for converting USB sticks from MBR to GPT so that they can be used as installation media, but I found nothing similar for ISO's. My suspicion is that the ISO somehow does not support UEFI but I don't know how to check this theory. All I see is that TianoCore detects the virtual DVD drive, but not the ISO in it.
Current config:
ROM=/mnt/vault/qemu/rom/Asus.GTX970.4096.140917.rom
DISK=/mnt/vault/qemu/img/win81-ovmf.qcow2
ISO1=/mnt/vault/qemu/iso/windows81pro64.iso
BIOS=/mnt/vault/qemu/ovmf/20150218
CODE=/mnt/vault/qemu/ovmf/20150218/OVMF_CODE-pure-efi.fd
VARS=/mnt/vault/qemu/ovmf/20150218/OVMF_VARS-pure-efi-windows81.fd
qemu-system-x86_64 \
-nodefconfig \
-drive if=pflash,format=raw,readonly,file=$CODE \
-drive if=pflash,format=raw,file=$VARS \
-enable-kvm \
-M pc-i440fx-2.1 \
-m 16384 \
-cpu host,kvm=off \
-smp 4,sockets=1,cores=4,threads=1 \
-rtc base=localtime \
-soundhw hda \
-device ioh3420,bus=pci.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,rombar=0,romfile=$ROM \
-device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 \
-drive file=$ISO1,media=cdrom \
-drive file=$DISK,media=disk \
-monitor stdio \
-vga cirrus/M
Last edited by Mysingen (2015-02-18 18:17:38)
Offline
100% cpu load, nothing on any output.
Pure nothing!
WTF?When booting bare metal, i can see the setup menu and even attempt to boot into windows7. But windows7 fails to output video signal after the starting logo.
UPD:
Alright, i've connected to qemu via gdb(had to set the mode manually), and..
I'm no low-level specialist, but something hints me that this won't work:(gdb) info reg rax 0x0 0 rbx 0x810248 8454728 rcx 0x402 1026 rdx 0x402 1026 rsi 0x10 16 rdi 0xbfed1060 3219984480 rbp 0xbff62ad0 0xbff62ad0 rsp 0xbff62ac0 0xbff62ac0 r8 0x1 1 r9 0x0 0 r10 0x36 54 r11 0xd7 215 r12 0x0 0 r13 0x0 0 r14 0x0 0 r15 0x0 0 rip 0xbed9d9df 0xbed9d9df eflags 0x246 [ PF ZF IF ] cs 0x28 40 ss 0x8 8 ds 0x8 8 es 0x8 8 fs 0x8 8 gs 0x8 8 (gdb) x/10i $rip => 0xbed9d9df: mov -0x8(%rbp),%rax 0xbed9d9e3: test %rax,%rax 0xbed9d9e6: je 0xbed9d9df 0xbed9d9e8: leaveq 0xbed9d9e9: retq 0xbed9d9ea: push %rbp 0xbed9d9eb: mov %rsp,%rbp 0xbed9d9ee: sti 0xbed9d9ef: pop %rbp 0xbed9d9f0: retq
Well, I have good news and bad news.
Good news:
I did this:
(gdb) x/10b 0xbed9d9df
0xbed9d9df: 0x48 0x8b 0x45 0xf8 0x48 0x85 0xc0 0x74
0xbed9d9e7: 0xf7 0xc9Got some bytes from here, like: 0x48 0x8b ... 0x74 0xf7 0xc9.
So i've used bgrep to search for this sequence of bytes in all my binaries being loaded to QEMU... naaah, just kidding, i'm an idiot, so i did just
hexdump -C /usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd | grep "74 f7 c9"
001cdaf0 90 48 8b 45 f8 48 85 c0 74 f7 c9 c3 55 48 89 e5 |.H.E.H..t...UH..|and
hexdump -C ~/rom-parser/image_uefi.rom | grep "74 f7 c9".
Good news are - IT IS OVMF THAT IS BROKEN AND PREVENTING MY VM TO BOOT WITH MY HARDWARE
Bad news are - while I know who broke it, i don't know what section of the actual code does this.
Can someone skilled enough help me to advance further on fixing this bug?
P.S.
I'm tempted to just manually break that cycle by inserting instructions via gdb live, but i don't know how to do that.
EDIT:
Piece of code that wasn't included in previous post:
0xbed9d9d6: movq $0x0,-0x8(%rbp)
0xbed9d9de: nop
0xbed9d9df: mov -0x8(%rbp),%rax
=> 0xbed9d9e3: test %rax,%rax
0xbed9d9e6: je 0xbed9d9dfUPD:
Okay, I did something(actually, i've updated OVMF to the freshest git build) and now it just outputs "invalid ROM contents" to dmesg when trying to boot. Trying to pass the romfile option. That worked. Looks like i've accidentally flashed some piece of ROM somehow. Spooky.
UPD2:
Stopping qemu with GDB, changing that JE to JNE(really, one byte)... worked. When QEMU process continued, the GPU successfully fired-up and showed me graphikz. Le success. Well, now i have to write a little essay to EDK2-devel mailing list regarding that. Maybe someone more clever will fix it properly.
Last edited by Duelist (2015-02-18 20:03:30)
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 had the same problem with a card which turned out not to support GPU pass through.
Try loading your card from a ROM file (see bottom of post #1). I got mine from
http://www.techpowerup.com/vgabios/I had a lot of trouble with my 560ti within the VM regarding drivers, sleep functions, resets...right now I have it assigned to the host. I use a 6800 series ATI for the VM and it behaves, updates clean.
Thanks for your replies !
I tried the ROM file corresponding to my graphic card (Gainward Golden Sample 560 ti 1Gb) but there was no improvement... It seems that this graphic card is not very well suited for VGA passthrough...
Offline
Hi, I've tried sorting through the last 25 pages or so of this thread and I think I'm sort of on the right path. It seems as though the OP is wildly out of date, though; can anyone direct me toward a document which contain more up to date information (In particular, on setting up OVMF instead of using vga arbitration, or any information from someone who has had success using a physical disk instead of an image for qemu)
Offline
As a followup to my earlier posts, I've been playing with the various hv* options but unfortunately still haven't had any luck. I always get the "code 43" error in the device manager for the nvidia GPU and the vfio_pci_read_config and vfio_pci_write_config "bad address" errors.
I've tried every version of the nvidia drivers that supports the GTX 970 with no luck, 344.11 being the oldest.
My current qemu invocation is this:
#!/bin/bash VFIO_DEVS="01:00.0 01:00.1" sudo /opt/bin/vfio-bind ${VFIO_DEVS} NAME="Windows 8.1 Enterprise" MEM=8192 CORES=4 DRIVE=/home/jaeger/VMs/win81/win81.img CDROM=/home/jaeger/VMs/win81/win81entx64.iso VIRTIO=/home/jaeger/VMs/win81/virtio-win-0.1-81.iso OVMF=/home/jaeger/ovmf-x64 sudo QEMU_AUDIO_DRV=pa \ /usr/bin/qemu-system-x86_64 \ -name "${NAME}" \ -nographic \ -enable-kvm \ -cpu host,kvm=off,hv-time=off,hv-vapic=off,hv-relaxed=off \ -m ${MEM} \ -smp cores=${CORES},threads=1,sockets=1 \ -vga none \ -nodefconfig \ -drive if=pflash,format=raw,readonly,file=${OVMF}/OVMF_CODE-pure-efi.fd \ -drive if=pflash,format=raw,file=${OVMF}/OVMF_VARS-pure-efi.fd \ -device vfio-pci,host=01:00.0,multifunction=on \ -device vfio-pci,host=01:00.1 \ -drive file="${DRIVE}",format=raw,id=disk0,if=virtio \ -drive file="${CDROM}",format=raw,id=cd0,if=none \ -device ide-cd,drive=cd0 \ -drive file="${VIRTIO}",format=raw,id=cd1,if=none \ -device ide-cd,drive=cd1 \ -netdev bridge,id=net0 \ -device virtio-net-pci,netdev=net0 \ -soundhw hda \ -usbdevice host:046d:c52b \ -usbdevice host:03f0:0024Has anyone else seen the vfio_pci_read_config and vfio_pci_write_config errors?
For science, today I installed Fedora 21 on an extra hard drive and tested my setup using libvirt and virt-manager (vs. qemu command line under CRUX). Under Fedora 21 it works! So I know now that my hardware isn't to blame for the failures I've been experiencing, it's got to be somewhere in my qemu or kernel configuration, I guess.
Unfortunately I don't know what exactly to chase regarding the vfio_pci_{read,write}_config errors but at least I know that what I want to do is possible with this particular hardware config.
I dumped the xml from my libvirt VM for comparison but I don't see anything between it and my qemu command line that screams broken. That makes me think perhaps there's a kernel issue. Fedora includes a lot of things I'm not building into my own kernel like cgroups, etc., so I'll poke around and see if I can find something there. Maybe I'll try the Fedora kernel config on my CRUX machine.
Offline
[...]
I tried the ROM file corresponding to my graphic card (Gainward Golden Sample 560 ti 1Gb) but there was no improvement... [...]
I've used roms from other manufacturers (equal hardware specs; gpu/#core's/clock)
My process:
1. new win7 VM (base, sytem updates) for every rom file
2. shutdown; make copy of VM on host
3. boot copy; install video drivers (start with most recent, work back)
4. working? rename and file
I threw in the towel because I couldn't take advantage of any power saving features; VM's wouldn't recover from sleep or monitor wake. Force close through host, reboot to a corrupted VM image (every time, unrecoverable), and rollback to step 3.
Careful though: I have a wireless hdmi 460ti that lost it's wireless hdmi capability through this type of tinkering (i think). Can't find the card-specific rom for it so I gambled
Haven't tried with win8
Offline
#!/bin/bash VFIO_DEVS="01:00.0 01:00.1" sudo /opt/bin/vfio-bind ${VFIO_DEVS} NAME="Windows 8.1 Enterprise" MEM=8192 CORES=4 DRIVE=/home/jaeger/VMs/win81/win81.img CDROM=/home/jaeger/VMs/win81/win81entx64.iso VIRTIO=/home/jaeger/VMs/win81/virtio-win-0.1-81.iso OVMF=/home/jaeger/ovmf-x64 sudo QEMU_AUDIO_DRV=pa \ /usr/bin/qemu-system-x86_64 \ -name "${NAME}" \ -nographic \ -enable-kvm \ -cpu host,kvm=off,hv-time=off,hv-vapic=off,hv-relaxed=off \ -m ${MEM} \ -smp cores=${CORES},threads=1,sockets=1 \ -vga none \ -nodefconfig \ -drive if=pflash,format=raw,readonly,file=${OVMF}/OVMF_CODE-pure-efi.fd \ -drive if=pflash,format=raw,file=${OVMF}/OVMF_VARS-pure-efi.fd \ -device vfio-pci,host=01:00.0,multifunction=on \ -device vfio-pci,host=01:00.1 \ -drive file="${DRIVE}",format=raw,id=disk0,if=virtio \ -drive file="${CDROM}",format=raw,id=cd0,if=none \ -device ide-cd,drive=cd0 \ -drive file="${VIRTIO}",format=raw,id=cd1,if=none \ -device ide-cd,drive=cd1 \ -netdev bridge,id=net0 \ -device virtio-net-pci,netdev=net0 \ -soundhw hda \ -usbdevice host:046d:c52b \ -usbdevice host:03f0:0024
By emulator I meant '/usr/bin/qemu-system-x86_64'. I don't have my system running to test now, but are your variables getting passed through correctly? Have you tried removing all other devices besides the video card and image of your os? Maybe try passing through one of your USB controllers through, that is what I did instead of passing through single USB devices.
Offline
By emulator I meant '/usr/bin/qemu-system-x86_64'. I don't have my system running to test now, but are your variables getting passed through correctly? Have you tried removing all other devices besides the video card and image of your os? Maybe try passing through one of your USB controllers through, that is what I did instead of passing through single USB devices.
Ah, ok, thanks for the clarification. As far as I can tell the variables are all passed correctly. VirtIO drivers work fine, windows works fine, it's just the GPU that's giving me trouble. The USB devices work fine as well, for what that's worth. At least now that I know the setup works in Fedora 21 with libvirt I can try to narrow down the differences between the two installs.
Offline
My OVMF q35 booting is going strait to the UEFI command line. It doesn't see my drives. This is part of the libvirt xml:
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<source dev='/dev/mordor/EmmaPC'/>
<target dev='sda' bus='sata'/>
<boot order='2'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/media/Storage/OS/en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso'/>
<target dev='sdb' bus='scsi'/>
<readonly/>
<boot order='1'/>
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
</disk>This is with me trying the most basic of settings for the drive. I'm using the latest git source for virt-manager and libvirt.
Hope you can help because I really want to get this set up with q35 because of the better handling of AMD cards.
Thanks.
Len wrote:@mauorrizze Windows 7
It won't work with OVMF without some hacking , you can search for some posts about installing it from FAT32 USB drive .
Also , I think its better to use SCSI rather than AHCI . My drives defined as follows :
-drive file=/VMs/Win_Main.img,cache=writeback,format=raw,if=none,id=drive0,aio=threads \ -device virtio-blk-pci,drive=drive0,ioeventfd=on,bootindex=1 \ -device virtio-scsi-pci,id=scsi \ -drive file=/VMs/Win8.iso,id=iso_install,if=none \ -device scsi-cd,drive=iso_install \ -cdrom /VMs/virtio.iso \Good luck !
Offline
100% cpu load, nothing on any output.
..deep OVMF problems..
In case of VERY STRANGE behaviour with OVMF and qemu in general, you can turn on the debug console via adding following line to qemu startup options:
-debugcon file:debug.log -global isa-debugcon.iobase=0x402Actually, the dead loop appeared to be a ... CPU dead loop function, so it was intentional, heh. Turns out there was an error message in the debug console:
ASSERT /var/lib/jenkins/jobs/edk2/workspace/rpmbuild/rpm/BUILD/edk2.git/MdeModulePkg/Core/Dxe/Mem/Pool.c(475): CR has Bad SignatureI'll keep posting some updates on my problem, just in case it might get useful for someone later.
UPD:
Seems like GPU's UEFI oprom is broken. Deep debugging to be done... or not. Maybe i'll just sack the cards and buy something MORE working. Or try poking ASUS. Or something else. But seems like i'm damned with those cards and shall continue digging.
Last edited by Duelist (2015-02-19 17:46:34)
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 OVMF q35 booting is going strait to the UEFI command line. It doesn't see my drives. This is part of the libvirt xml:
<disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none' io='native'/> <source dev='/dev/mordor/EmmaPC'/> <target dev='sda' bus='sata'/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/media/Storage/OS/en-gb_windows_8.1_enterprise_with_update_x64_dvd_4048611.iso'/> <target dev='sdb' bus='scsi'/> <readonly/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk>
You should be using 'file' as the disk type for '/dev/mordor/EmmaPC'. This does not look like a valid block device, like /dev/sda2. Also you will want to change the target bus from SATA to IDE, and SCSI to IDE. Here is mine:
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source file='/home/user/virtual_machines/disks/GamingMachineOS.img'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/user/Disk_Images/Windows10_TechnicalPreview_x64_EN-US_9926.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>Offline
anickname wrote:I was researching that too, if anyone can confirm that the HD7790 has the reset problem, it might be affordable enough that I could pick one up for testing.
Yes, the HD7790 has the reset problem.
Ok, I'll try to keep an eye out for a cheap one on ebay
Was the HD7790 reset problem ever addressed, if so, can somebody link to the resolution?
Offline
Hello everyone. Thank you all for this guide. I have been able to pass through an Nvidia 970 card to Windows 8.1 and had it working. Briefly... Then the driver detected the virtualization and threw up Code 43.
The problem seems to be that I am not booting with OVMF even though I try to. When I point directly to the TianoCore firmware, the ISO is not detected as bootable:
-drive if=pflash,format=raw,readonly,file=/mnt/vault/qemu/ovmf/20150218/OVMF_CODE-pure-efi.fd -drive if=pflash,format=raw,file=/mnt/vault/qemu/ovmf/20150218/OVMF_VARS-pure-efi.fdI first suspected that I was missing other component such as ipxe.git, etc, due to dangling symlinks in the 20150218 directory and installed those as well. But it doesn't help. When I point to the entire 20150218 directory (which contains a symlink bios.bin -> OVMF-pure-efi.fd), QEMU boots with SeaBios instead:
-L /mnt/vault/qemu/ovmf/20150218Any idea what I might be doing wrong? There are guides on the net for converting USB sticks from MBR to GPT so that they can be used as installation media, but I found nothing similar for ISO's. My suspicion is that the ISO somehow does not support UEFI but I don't know how to check this theory. All I see is that TianoCore detects the virtual DVD drive, but not the ISO in it.
/M
Problem solved, partly.
It turns out that there (reasonably) must be a bug in OVMF. I could install by first formatting a USB stick as GPT+FAT32, copy all files from the Win8.1 ISO over to it and then pass the physical USB stick on to OVMF which then detected its file system and let me boot the installation from it.
After that, I was able to install Nvidia 344.11 drivers and it actually worked really well. I restarted the VM a great number of times and played Mass Effect for a few hours. However...
At some point Mass Effect started to crash on startup and I tried to solve the problem by installing newer drivers. Since then I always get Error 43. What baffles me is that I now get Error 43 even after completely starting over with the original working formula, including a fresh copy of the OVMF VARS file. I cannot for my life understand how the driver can see *this* time that it is running under virtualization, while it didn't the first time. Absolutely astonishing.
Offline
At some point Mass Effect started to crash on startup and I tried to solve the problem by installing newer drivers. Since then I always get Code 43. What baffles me is that I now get Code 43 even after completely starting over with the original working formula, including a fresh copy of the OVMF VARS file. I cannot for my life understand how the driver can see *this* time that it is running under virtualization, while it didn't the first time. Absolutely astonishing.
What is even weirder is that now the damn thing works again! All I did was to restart the host a couple of times. Posts from normal Windows users on the net give me the idea that Code 43 is a generic cannot-initialize-the-card-for-whatever-reason kind of thing. And that it happens on windows *hosts* under a very wide range of conditions. I haven't actually used Windows at home since 1997. Now I'm rather extra happy to not let it near the bare metal and especially not my host BIOS. Quirky stuff.
Last edited by Mysingen (2015-02-20 02:09:11)
Offline
I am running into a very strange issue. On Intel I 'm passing through a GTX 460 and using internal graphics for the host, which works perfectly except for when the guest is shut down and started again (asks for rom and throws irqs, then freezes up the host completely). This in itself is not a problem as I can use the suspend/resume trick.
The weird part is if I try to use virtio-net instead of e1000, windows will get to the spinning logo and then dmesg will show irq 34 or 35 for the gtx460, at which point the host will freeze. Also, if the virtio driver is not installed but the device is still emulated, it does not crash.
Has anyone else had a similar issue with virtio-net?
Offline