You are not logged in.
Does it work that way? If so - ignore that lines. You can get rid of those lines by deleting
QEMU_ALSA_DAC_BUFFER_SIZE=512 QEMU_ALSA_DAC_PERIOD_SIZE=170
When it rejects those settings the audio doesn't sound properly.
And if you don't care much about using pulse audio or not - you can and should adapt QEMU to use it:
QEMU_PA_SAMPLES=128 QEMU_AUDIO_DRV=pa
I have used those pa settings previously within KDE5 and they produced static quite frequently.
In addition, using those pa settings give an error within awesome:
pulseaudio: pa_context_connect() failed
pulseaudio: Reason: connection refused
pulseaudio: Failed to initialize PA contextaudio: Could not init 'pa' audio driver
From what I've gathered, it may be caused by running pa in single user mode and not system mode.
But because those settings give static, I believe there is no reason to pursue this further.
Any clue as to why it rejects the alsa settings?
Thanks.
Offline
I have an FX-8350 + GA990FXA-UD3, with 270x as passthrough GPU and 5770 as linux GPU. I want to upgrade my 270x to something faster. Does the r9 290/390 or the r9 285/380 work correctly, without reset issues?. Thanks.
My Sapphire Tri-X R9 290X works fine with no issues at all (if only this card was a little bit smaller ...), with VM Windows 7 and regular Catalyst drivers. No gotchas, it just works. I am not using UEFI boot, so cannot say how this card would behave with OVMF. Also, I am using workstation class motherboard SuperMicro X9DA7, no idea how yours would work with this card.
I would advice against R9 285. I was unable to make FirePro W7100 work with pass-through and it uses the same chip Tonga PRO. Of course the reason for this could be specific to W7100 (ASIC or firmware), not to the chip. But on the other hand ...
Last edited by Bronek (2015-07-31 09:32:45)
Offline
I'm not having much luck installing Windows7 Pro using OVMF at the moment.
I've got a fully working Windows8.1 Enterprise Machine with OVMF that I've been using for months and months, but I would like to try Windows10 as a free upgrade which you can't do from an enterprise version so I am currently trying to get Windows7 Pro working.
I'm using libvirt XML files to start the VM, I've assigned the QXL vga adapter, as well as my AMD Radeon R290 card, I can boot from the Windows7 ISO which I see on the QXL adapter via VNC that it shows "Windows is loading files" progress then it goes to "Starting Windows" and just crashes.
I can see that there have been issues reported with the OVMF builds so I've tried multiple builds:
The latest from https://www.kraxel.org/repos/jenkins/edk2/ (31st July)
15214
16229
17542
And finally the custom one from lersek based on 18063 http://people.redhat.com/~lersek/ovmf-r … -4530eb75/
All of them do the same, just appear blank/crashed after "Starting Windows" before you get to the installation screen.
I've also tried dropping in to the EFI Shell and manually starting the Windows7 EFI boot application as per https://technet.microsoft.com/en-gb/lib … s.10).aspx
Any one have any ideas?
Software Versions:
qemu-2-4-0-rc3
libvirt version: 1.2.15
Hardware:
Intel i7-4770s
Jetway NF9J-Q87
AMD Radeon R290
Here's my current XML file:
<domain type='kvm'>
<name>windows7</name>
<uuid>7b222825-fc7d-4a66-a72c-5875063752d2</uuid>
<memory unit='KiB'>5291456</memory>
<currentMemory unit='KiB'>5291456</currentMemory>
<vcpu placement='static'>2</vcpu>
<cputune>
<vcpupin vcpu='0' cpuset='2'/>
<vcpupin vcpu='1' cpuset='3'/>
</cputune>
<os>
<type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type>
<loader readonly='yes' type='pflash'>/home/root/ovmf-builds/15214/OVMF.fd</loader>
<boot dev='cdrom'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
<hyperv>
<relaxed state='on'/>
<vapic state='on'/>
<spinlocks state='on' retries='8191'/>
</hyperv>
<kvm>
<hidden state='on'/>
</kvm>
</features>
<cpu mode='host-passthrough'/>
<clock offset='localtime'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
<timer name='hypervclock' present='yes'/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/local/qemu-2-4-0-rc3/bin/qemu-system-x86_64</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' />
<source file='/virtualguests/windows7/windows7-c-drive.qcow2'/>
<target dev='vdb' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/root/virtualguestisos/windows7/Windows_7_64-bit_Professional_x64.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/root/virtualguestisos/virtio-isos/virtio-win-0.1-74.iso'/>
<target dev='hdd' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' unit='1'/>
</disk>
<controller type='pci' index='0' model='pci-root' />
<interface type='bridge'>
<mac address='52:54:00:12:34:76'/>
<source bridge='br0'/>
<target dev='tap8'/>
<model type='e1000'/>
<alias name='virtio'/>
<rom bar='off'/>
</interface>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<vendor id='0x046d'/>
<product id='0xc52e'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<vendor id='0x045e'/>
<product id='0x0719'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<vendor id='0x1415'/>
<product id='0x2000'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<vendor id='0x0fcf'/>
<product id='0x1009'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x01' slot='0x00' function='0x0' />
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</hostdev>
<memballoon model='none'/>
<graphics type='vnc' port='5903' autoport='no' listen='0.0.0.0'>
<listen type='address' address='0.0.0.0'/>
</graphics>
<video>
<model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
</devices>
</domain>
Thanks
Graham
Offline
I've just managed to progress further but without using libvirt, just plain qemu command line. I can now see the Windows7 pro Installation Screen in VNC via QXL.
Have also gone back to 16229, as it looks like 15214 doesnt work for Windows7. http://ubuntuforums.org/showthread.php?t=2262351
I did try 16229 in libvirt but I couldn't get it working.
I'll post my progress after installation.
Command line used:
/usr/local/qemu-2-4-0-rc3/bin/qemu-system-x86_64 \
-enable-kvm \
-m 4096 \
-cpu host,kvm=off \
-drive if=pflash,format=raw,readonly,file=/home/root/ovmf-builds/16229/usr/share/ovmf/ovmf_x64.bin \
-device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
-drive file=/virtualguests/windows7/windows7-c-drive.qcow2,if=none,id=drive-virtio-disk1,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 \
-drive file=/home/root/virtualguestisos/windows7/Windows_7_64-bit_Professional_x64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw \
-device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 \
-drive file=/home/root/virtualguestisos/virtio-isos/virtio-win-0.1-74.iso,if=none,id=drive-ide0-1-1,readonly=on,format=raw \
-device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x3 \
-device usb-host,hostbus=1,hostaddr=5,id=hostdev0 \
-device usb-host,hostbus=1,hostaddr=11,id=hostdev1 -device usb-host,hostbus=1,hostaddr=3,id=hostdev2 \
-device usb-host,hostbus=1,hostaddr=9,id=hostdev3 -device vfio-pci,host=01:00.0,id=hostdev4,bus=pci.0,multifunction=on,addr=0x8 -device vfio-pci,host=01:00.1,id=hostdev5,bus=pci.0,addr=0x9 \
-vnc 0.0.0.0:3
Last edited by gneville (2015-07-31 12:00:10)
Offline
Windows7 Pro Installed worked and finished.
After first reboot of installation it dropped back to EFI Shell, had to manually start from HDD:
FS1:
\EFI\Boot\bootx64.efi
After "Completing Installation" it again dropped back EFI Shell, again manually started EFI from HDD:
FS1:
\EFI\Boot\bootx64.efi
Now progressed in to setup of Username and computer name and Product Key and finally Win7 desktop
Downloaded AMD Catalyst 15.7.1 and installed and rebooted now got Windows7 desktop on AMD HDMI Port.
Offline
@gneville:
I have problems installing windows7 on OVMF since... 18 of july.
I don't know what causes it, as i failed to attach the debug console.
Glad to see you've managed to finish it up via commandline.
It just hangs when the setup-from-hard-drive starts to boot up.
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
Worth trying the OVMF files from here : https://www.archlinux.org/packages/extra/any/ovmf/
The issue I've got now is on each boot I have to manually start the EFI boot in the EFI Shell. Hoping that after I get to Upgrade Win7 Pro to Win10 Pro and then finally to a clean install I won't need to worry.
@gneville:
I have problems installing windows7 on OVMF since... 18 of july.
I don't know what causes it, as i failed to attach the debug console.
Glad to see you've managed to finish it up via commandline.
It just hangs when the setup-from-hard-drive starts to boot up.
Offline
Worth trying the OVMF files from here : https://www.archlinux.org/packages/extra/any/ovmf/
The issue I've got now is on each boot I have to manually start the EFI boot in the EFI Shell. Hoping that after I get to Upgrade Win7 Pro to Win10 Pro and then finally to a clean install I won't need to worry.
Duelist wrote:@gneville:
I have problems installing windows7 on OVMF since... 18 of july.
I don't know what causes it, as i failed to attach the debug console.
Glad to see you've managed to finish it up via commandline.
It just hangs when the setup-from-hard-drive starts to boot up.
Your issue is just a matter of configuration - specify the boot order, and you should be fine.
Although i do have pacman installed(i am one curious bastard), i use OVMF from git and i have fedora.
Could you tell me the build number which works for you?
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
The main requirement for a device to be passed through is to have a valid IOMMU group. Period.
If there's a device you want in the same group with the devices you want to leave for the host - you'll have to p-t the whole group with all it's devices.
OR
use old, legacy, deprecated, xen pci-assign.
It works as vfio for regular PCI devices, and also doesn't require iommu groups to be valid. In fact, that's the only way i got my third GPU passed-through.The problem you have usually happens when there's a malfunctioning windows driver. So the device is passed-through fine(check dmesg for errors btw), it's the drivers(or the windows kernel) who's glitching. As you can guess by the error message, check virtio-scsi driver(update it maybe?) and also check for the right IRQLs set for the sound card you've p-t'd. They really like interrupts.
I am passing my embedded on the motherboard
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller (rev 01)
via pci-assign and i haven't observed any problems so far.
And what's that "kernel_irqchip=on" you have there? You sure you need it and you know how it works?
Thank you for the response. It seems to be a Windows issues then. kernel-irqchip=on is enabled by default for qemu I believe, not sure why I explicitly added it but I don't think it makes any difference.
@mutiny
Conventional PCI devices often don't support or have broken support for interrupt masking. You can try using the vfio-pci module option nointxmask=1 to mask it at the APIC rather than the device, but this imposes the requirement that the device uses an exclusive interrupt. If you find the interrupt shared with other drivers, you'll need to unbind those conflicting devices from host drivers. If you have multiple conventional PCI devices behind the same PCIe-to-PCI bridge, the IOMMU cannot distinguish between them and therefore they are necessarily grouped together. The deprecated pci-assign driver (which has nothing to do with xen) will allow assigning such device separately, but it's much, much worse than ignoring the lack of isolation between PCIe devices and not recommended imho.
Thank you very much aw. I will try with these options and see what happens. It is the only conventional PCI device I have installed at the moment, the other PCI slot is not populated.
Offline
@Duelist
The build - ovmf 16229-1 - is directly here: https://www.archlinux.org/packages/extra/any/ovmf/
I've now successfully upgraded the Win7 Pro Guest to Windows10 Pro and all works with OVMF. I've grabbed my new Win10 Pro product key and I've successfully performed a clean build of Windows10 Pro using OVFM as well. AMD Catalyst 15.7.1 installed and working fine with Win10. No reset issues either.
gneville wrote:Worth trying the OVMF files from here : https://www.archlinux.org/packages/extra/any/ovmf/
The issue I've got now is on each boot I have to manually start the EFI boot in the EFI Shell. Hoping that after I get to Upgrade Win7 Pro to Win10 Pro and then finally to a clean install I won't need to worry.
Duelist wrote:@gneville:
I have problems installing windows7 on OVMF since... 18 of july.
I don't know what causes it, as i failed to attach the debug console.
Glad to see you've managed to finish it up via commandline.
It just hangs when the setup-from-hard-drive starts to boot up.Your issue is just a matter of configuration - specify the boot order, and you should be fine.
Although i do have pacman installed(i am one curious bastard), i use OVMF from git and i have fedora.
Could you tell me the build number which works for you?
Offline
You can't stop the progress...
Oh well. The time has come.
I have successfully installed Windows 10.
And damn it kind of frightened me when it didn't finish downloading the catalyst driver setup, but already installed the drivers.
Creepy stuff.
There's a good thing in all this modern hell: the screensaver settings menu remains the same for the damn 15 years. Yeah, that one where you cohoose the screensaver, with the funky drawn CRT-screen on it. It's the same as in Windows XP or W2K. I remember what a huge progress it was when that CRT screen changed it's design compared to 9x systems...
Anyway, Catalyst installed, crossfire launched, OVMF works. QXL is not needed.
AMD site hints me that my cards support DirectX 12.
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
Hey all,
I really need your help.
For months everything has been worked perfectly with VGA passthrough.
I have made a new Gentoo install as well and could enable the VGA passthrough there too.
Then something must have happened, after a few weeks of no-gaming, i tried to play some games, but after around 10 mins of gaming it became laggier and laggier, after one minute i got blank screen, and the following error message in terminal:
qemu-system-x86_64: vfio: Unable to power on device, stuck in D3
If i try to launch qemu again, ill get the following:
qemu-system-x86_64: -device vfio-pci,host=01:00.0,x-vga=on: vfio: Error: Failed to setup INTx fd: Device or resource busy
qemu-system-x86_64: -device vfio-pci,host=01:00.0,x-vga=on: Device initialization failed
qemu-system-x86_64: -device vfio-pci,host=01:00.0,x-vga=on: Device 'vfio-pci' could not be initialized
dmesg:
[ 3933.246342] genirq: Flags mismatch irq 16. 00000000 (vfio-intx(0000:01:00.0)) vs. 00000080 (ehci_hcd:usb1)
[ 3933.267313] vfio-pci 0000:01:00.0: Refused to change power state, currently in D3
[ 3933.977098] vfio-pci 0000:01:00.0: timed out waiting for pending transaction; performing function level reset anyway
qemu command:
sudo qemu-system-x86_64 -enable-kvm -m 8196 -cpu host,kvm=off -smp 4 -device vfio-pci,host=01:00.0,x-vga=on -device vfio-pci,host=01:00.1 -vga none -hda /mnt/harddrives/ssd/win8.qcow2 -usb -usbdevice host:1532:0032 -usbdevice host:1532:0109 -soundhw hda
I need to reboot the PC, then i can use qemu again (for 10 mins).
Noone seem to share this error with me on google.
Since i had backup from old Arch installation, where everything worked perfectly, i have restored everything, problem still persists.
I tried to downgrade apps, new install, fiddle with kernel, still no luck.
Getting desperate here, from time to time i like to play but dont want to switch back to windows ><
Please hep me if u can, and let me know if u need some more infos.
Thanks in advance.
Last edited by dragonreborn (2015-08-01 12:51:40)
Offline
@dragonreborn
There's a disable_idle_d3=1 option to vfio-pci in v4.1 that you might want to try. If D3 state is this broken for your device, it should probably be blacklisted in the kernel.
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
@dragonreborn
There's a disable_idle_d3=1 option to vfio-pci in v4.1 that you might want to try. If D3 state is this broken for your device, it should probably be blacklisted in the kernel.
My bad.
Naturally after a couple of weeks trying to figure it out, and then writing on this forum, I figured it out.
It's most probably a hardware fault, fans aren't working on vga at all. Caused the card to overheat and stop working in 10 minutes.
Tried out the 2nd bios as well, no luck, no spin up at boot either.
I'll try a native windows out with the Evga software, otherwise back to RMA. Thanks for the help nevertheless!
Offline
@gneville:
I have problems installing windows7 on OVMF since... 18 of july.
I don't know what causes it, as i failed to attach the debug console.
Glad to see you've managed to finish it up via commandline.
It just hangs when the setup-from-hard-drive starts to boot up.
Just two quick notes.
First, I verified Windows 7 right now. I built OVMF from edk2 SVN r18122 (git 7669f734). Both the installer ISO ("en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso") and my preexistent guest boot to the GUI just fine, using QXL.
Second, I don't understand why you said "i failed to attach the debug console" again. I explained in excruciating detail how you should edit the domain XML, here: https://bbs.archlinux.org/viewtopic.php … 2#p1548842 . You didn't react to that comment, so I guess you either missed it, or didn't read it far enough for the actual XML snippet.
Offline
Hey Guys!
I have been trying to get GPU passthrough to work, but cannot seem to find out where the problem lies, since I do not get any errors.
I have primarily used these guides as sources:
http://ubuntuforums.org/showthread.php?t=2262280
https://www.pugetsystems.com/labs/artic … 4-KVM-585/
https://bbs.archlinux.org/viewtopic.php?id=162768
Specs:
Lubuntu 14.04 with patched 3.18.0 kernel
GTX 750TI
i5 4690K (VT-d enabled)
Gigabyte Z97 D3H
TV with multiple outputs (VGA, HDMI)
The IGPU runs over VGA, whereas the GPU is connected via HDMI.
I use the IGPU for the host system, while attempting to pass the GTX 750TI through to the Guest.
Both are connected to one single TV.
When I run the script, a qemu window pops up saying "compat_monitor0 console Qemu 2.1.2 monitor - type help
When I switch to the HDMI output of the TV, to which the CPU is connected, nothing appears. However, my GPU usage ramps up to 25%, hence something must be going on.
http://s18.postimg.org/9u9hg6v61/qemu.png
When I assign one of the downloaded gpu roms in the script, the colors become fuzzy and inverted (which cannot be seen on the screen), while nothing appears on the HDMI output and the cpu usage only momentarily rises, while dropping shortly after:
http://postimg.org/image/4txnlf85x/
Prepwork:
.)I compiled, patched and installed kernel 3.18.0 with ACS and i915: http://ubuntuforums.org/showthread.php?t=2262280
.)Downloaded a rom file for my GPU (GTX 750 TI): http://www.techpowerup.com/vgabios/inde … =&memSize=
.)Upgraded Qemu to version 2.1.2 via this ppa:jacob/virtualisation
.)Installed all necessary packages as suggested by this guide: https://help.ubuntu.com/community/KVM/Installation
1.)Grub
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on vfio_iommu_type1.allow_unsafe_interrupts=1 pcie_acs_override=downstream i915.enable_hd_vgaarb=1"
GRUB_CMDLINE_LINUX=""
2.)Nvidia IDs
lspci -nn | grep NVIDIA
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] [10de:1380] (rev a2)
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:0fbc] (rev a1)
3.)/etc/initramfs-tools/modules
pci_stub ids=10de:1380,10de:0fbc
4.)/etc/vfio-pci.cfg
0000:01:00.0
0000:01:00.1
5.)Here my script (Here without a rom file assigned, this can be seen in the screen above)
#!/bin/bash
configfile=/etc/vfio-pci.cfg
vfiobind() {
dev="$1"
vendor=$(cat /sys/bus/pci/devices/$dev/vendor)
device=$(cat /sys/bus/pci/devices/$dev/device)
if [ -e /sys/bus/pci/devices/$dev/driver ]; then
echo $dev > /sys/bus/pci/devices/$dev/driver/unbind
fi
echo $vendor $device > /sys/bus/pci/drivers/vfio-pci/new_id
}
modprobe vfio-pci
cat $configfile | while read line;do
echo $line | grep ^# >/dev/null 2>&1 && continue
vfiobind $line
done
sudo qemu-system-x86_64 -enable-kvm -M q35 -m 4096 -cpu host,kvm=off \
-smp 4,sockets=1,cores=4,threads=1 \
-bios /usr/share/qemu/bios.bin -vga none \
-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=/home/jackson/windows.img,id=disk,format=raw -device ide-hd,bus=ide.0,drive=disk \
-drive file=/home/jackson/Downloads/windows.iso,id=isocd -device ide-cd,bus=ide.1,drive=isocd \
-boot menu=on
exit 0
Please help me find out what's wrong.
Thank you!
Last edited by morphological (2015-08-02 06:52:18)
Offline
Please ask on your distro's boards, we only support Arch: https://wiki.archlinux.org/index.php/Fo … pport_ONLY
Offline
@morphological
I have no experience with getting VGA passthrough working on Lubuntu, but I did get it working with both Fedora 22 and Arch, with both Windows 7 and Windows 10 technical preview, with the same video card & very similar GPU (i5-4690. "K" versions usually do not support VT-d but according to ARK yours does, so that's good). You should use the UEFI method and do not patch your kernel with the i915 VGA arbiter patch; your video card supports it. Also, you do not need to download a ROM for the card. Be advised, you will need to use this version of the OVMF binaries. Without it, the install will start but fail (with no messages... very maddening).
If you have access to/a license for Windows 10, I recommend using it over 7. For me at least, it performed much better. I can't speak to Windows 8/8.1.
You didn't mention using Alex Williamson's blog as a guide. You should read it. This forum is way too long, and the blog condenses what you need to know down into a few good posts. I linked you at part 3; you should read & follow it and part 4. The comments are helpful too; there are not many to sift through.
Offline
I can confirm also that edk2 SVN r18123, which I got from here https://www.kraxel.org/repos/jenkins/edk2/ , works for me when Installing and Running Windows7
However I can only get it working still via qemu command line.
@lersek have you managed to get Windows7 working via libvirt? If so could you provide a copy of your XML file?
Edit: I've managed to get it working now with libvirt, I had to take away some of the hyper-v settings:
<features>
<hyperv>
<relaxed state='on'/>
<vapic state='on'/>
<spinlocks state='on' retries='8191'/>
</hyperv>
</features>
<clock>
<timer name='hypervclock' present='yes'/>
</clock>
Edit2: Speifying the nvram file, got me past the issue where I'd always have to manually boot the UEFI bootloader e.g. FS1: \EFI\Boot\bootx64.fd. I had to change the boot order in the Tiano Core BIOS and have it.
Here's my XML file in case anyone wants to refer to it:
<domain type='kvm'>
<name>windows7</name>
<uuid>7b222825-fc7d-4a66-a72c-5875063752d2</uuid>
<memory unit='KiB'>5291456</memory>
<currentMemory unit='KiB'>5291456</currentMemory>
<vcpu placement='static'>2</vcpu>
<cputune>
<vcpupin vcpu='0' cpuset='2'/>
<vcpupin vcpu='1' cpuset='3'/>
</cputune>
<os>
<type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type>
<loader type='pflash' readonly='yes'>/home/root/ovmf-builds/ovmf-jenkins/ovmf-x64-02082015/usr/share/edk2.git/ovmf-x64-18123/OVMF-pure-efi.fd</loader>
<nvram>/home/root/ovmf-builds/ovmf-jenkins/ovmf-x64-02082015/usr/share/edk2.git/ovmf-x64-18123/OVMF_VARS-pure-efi.fd</nvram>
<boot dev='cdrom'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
<kvm>
<hidden state='on'/>
</kvm>
</features>
<cpu mode='host-passthrough'/>
<clock offset='localtime'>
<timer name='rtc' tickpolicy='catchup'/>
<timer name='pit' tickpolicy='delay'/>
<timer name='hpet' present='no'/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/local/qemu-2-4-0-rc3/bin/qemu-system-x86_64</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' />
<source file='/virtualguests/windows7/windows7-c-drive.qcow2'/>
<target dev='vdb' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/root/virtualguestisos/windows7/Windows_7_64-bit_Professional_x64.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/home/root/virtualguestisos/virtio-isos/virtio-win-0.1-74.iso'/>
<target dev='hdd' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' unit='1'/>
</disk>
<controller type='pci' index='0' model='pci-root' />
<interface type='bridge'>
<mac address='52:54:00:12:34:76'/>
<source bridge='br0'/>
<target dev='tap8'/>
<model type='e1000'/>
<alias name='virtio'/>
<rom bar='off'/>
</interface>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<vendor id='0x046d'/>
<product id='0xc52e'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<vendor id='0x045e'/>
<product id='0x0719'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<vendor id='0x0fcf'/>
<product id='0x1009'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x01' slot='0x00' function='0x0' />
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/>
</source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
</hostdev>
<memballoon model='none'/>
<graphics type='vnc' port='5903' autoport='no' listen='0.0.0.0'>
<listen type='address' address='0.0.0.0'/>
</graphics>
<video>
<model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1'/>
</video>
</devices>
</domain>
Thanks
Duelist wrote:@gneville:
I have problems installing windows7 on OVMF since... 18 of july.
I don't know what causes it, as i failed to attach the debug console.
Glad to see you've managed to finish it up via commandline.
It just hangs when the setup-from-hard-drive starts to boot up.Just two quick notes.
First, I verified Windows 7 right now. I built OVMF from edk2 SVN r18122 (git 7669f734). Both the installer ISO ("en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso") and my preexistent guest boot to the GUI just fine, using QXL.
Second, I don't understand why you said "i failed to attach the debug console" again. I explained in excruciating detail how you should edit the domain XML, here: https://bbs.archlinux.org/viewtopic.php … 2#p1548842 . You didn't react to that comment, so I guess you either missed it, or didn't read it far enough for the actual XML snippet.
Last edited by gneville (2015-08-02 13:13:43)
Offline
Duelist wrote:@gneville:
I have problems installing windows7 on OVMF since... 18 of july.
I don't know what causes it, as i failed to attach the debug console.
Glad to see you've managed to finish it up via commandline.
It just hangs when the setup-from-hard-drive starts to boot up.Just two quick notes.
First, I verified Windows 7 right now. I built OVMF from edk2 SVN r18122 (git 7669f734). Both the installer ISO ("en_windows_7_professional_with_sp1_x64_dvd_u_676939.iso") and my preexistent guest boot to the GUI just fine, using QXL.
Second, I don't understand why you said "i failed to attach the debug console" again. I explained in excruciating detail how you should edit the domain XML, here: https://bbs.archlinux.org/viewtopic.php … 2#p1548842 . You didn't react to that comment, so I guess you either missed it, or didn't read it far enough for the actual XML snippet.
Thanks, i've missed that post because i've posted an answer to someone else's post the moment you've posted. Thanks!
Strangely though, i remember specifying the namespace, and libvirt didn't object on the syntax, however i didn't check for the actual QEMU command line produced. Will test again soon.
Edit2: Speifying the nvram file, got me past the issue where I'd always have to manually boot the UEFI bootloader e.g. FS1: \EFI\Boot\bootx64.fd. I had to change the boot order in the Tiano Core BIOS and have it.
Well, usually libvirt makes a copy of the OVMF_VARS file, where all the variale stuff are stored. Yeah, boot order is there too. If the loader is specified there, OVMF doesn't do it's "scan for all loaders" routine and boots the next available device, which is PXE, i guess. I might be wrong in that sentence.
I don't know why your VM didn't make that copy.
---
It's most probably a hardware fault, fans aren't working on vga at all. Caused the card to overheat and stop working in 10 minutes.
I wasn't swift enough to tell that this is really an overheating case.
Please ask on your distro's boards, we only support Arch: https://wiki.archlinux.org/index.php/Fo … pport_ONLY
How about us ignoring that rule for another two years please? I run fedora, and all my messages belong to this particular topic because that thread is the only thread on the net with that much of activity and info. There are lersek(who's the developer of OVMF) and aw(who's the (redhat i guess) developer of vfio).
Most of the questions are not distro-specific, anyway. If the arch packages differ from what others are using, it's only either a more fresh version of an upstream package, or with some very rare and specific patches like OVMF with sata booting.
Last edited by Duelist (2015-08-02 19:40:38)
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 switched to Windows 10. I found a comment on Alex's blog a while ago that suggested that on Win 10 Nvidia's driver only does Hyper-V checks when the system reboots.
Peculiarly, it is so. I've been running the VM with HV enlightenments on and it keeps working after several shutdown/start cycles. Only when the guest is rebooted or started up after a crash, does the driver crap out with code 43 (edit: and during driver installation, I would assume). Likewise when in code 43 state, the guest must be rebooted when HV is off to fix it. Afterwards HV can be enabled again. The same behaviour happens with a quadro. I mentioned earlier that the quadro driver also detects HV but instead of refusing to work it runs in some kind of degraded mode (tldr: refresh rates are capped and some other functionality is missing in control panel).
Now I can get 144 Hz output to my monitor without sacrificing HV. Since I'm avoiding the HV checks anyway, I'm running with Geforce pci ids instead of Quadro's so overclocking tools work to their full extent as well.
Edit 2: I wonder if this is because of Fast Boot? Win 8 has it too, but I can't remember if I had it enabled. It's worth noting that libvirt seems to disable hibernation by default which prevents Fast Boot from working.
Last edited by impulse_255 (2015-08-02 20:35:46)
Offline
jasonwryan wrote:Please ask on your distro's boards, we only support Arch: https://wiki.archlinux.org/index.php/Fo … pport_ONLY
How about us ignoring that rule for another two years please? I run fedora, and all my messages belong to this particular topic because that thread is the only thread on the net with that much of activity and info. There are lersek(who's the developer of OVMF) and aw(who's the (redhat i guess) developer of vfio).
Most of the questions are not distro-specific, anyway. If the arch packages differ from what others are using, it's only either a more fresh version of an upstream package, or with some very rare and specific patches like OVMF with sata booting.
No. There are support communities for those distributions; these boards are for Arch.
Offline
Duelist wrote:jasonwryan wrote:Please ask on your distro's boards, we only support Arch: https://wiki.archlinux.org/index.php/Fo … pport_ONLY
How about us ignoring that rule for another two years please? I run fedora, and all my messages belong to this particular topic because that thread is the only thread on the net with that much of activity and info. There are lersek(who's the developer of OVMF) and aw(who's the (redhat i guess) developer of vfio).
Most of the questions are not distro-specific, anyway. If the arch packages differ from what others are using, it's only either a more fresh version of an upstream package, or with some very rare and specific patches like OVMF with sata booting.No. There are support communities for those distributions; these boards are for Arch.
Ok, seeya. I thought this board was open to productive, distro agnostic discussions, but if non-Arch users are going to get turned away, you'll need to find another expert.
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
Please ask on your distro's boards, we only support Arch: https://wiki.archlinux.org/index.php/Fo … pport_ONLY
What? Why? we've been using this forum for 2 years now for everything and everyone related to gpu passthrough, so why now? make no sense
Last edited by nbhs (2015-08-02 22:43:57)
Offline
jasonwryan wrote:Please ask on your distro's boards, we only support Arch: https://wiki.archlinux.org/index.php/Fo … pport_ONLY
What? Why? we've been using this forum for 2 years now for everything and everyone related to gpu passthrough, so why now? make no sense
We have the policy for a reason. This thread is no different to the rest of the boards; so, yes, it does make sense, it is entirely consistent with the overall approach.
Offline