vfio vga-current
i found out that you offer two new up to date git repos. i cloned both to my hdd and compiled them worked fine. but i still get an BSOD (0x116) this error only occurs if the display driver cant reset the card. now i would like to know since i guess i have done everything correctly how can i check if i have not made a mistake by accident. i cloned the git repos by: git clone git://github.com/awilliam/linux-vfio -b vga-current and similar to qemu. im using the ubuntu 13.10 seabios (1.7.3) ty for your help... -- Adiumentum GmbH Gf. Martin Wolf Banderbacherstraße 76 90513 Zirndorf 0911 / 9601470 mw...@adiumentum.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga passthrough // vfio // qemu bridge
I just started over because of several small glitches that came from constantly reinstalling qemu. im still using saucy 13.10 alpha for the tests with a modified ubuntu kernel (with alex patch) and since i found out that the patches of alex are now pulled into qemu 1.6 i chose to use qemu git. after some perparation (apt-get build-depends qemu) i configured qemu with (./configure --target-list=x86_64-softmmu) and installed it to /usr/local. when i wanted to start qemu-system-x64 the screen connected to the 7870 still did not start (the usb devices were instantly pulled so something must have happened). then i tried the seabios supplied by ubuntu(1.7.3), then the screen went on , but after the driver installation i got a bluescreen connected to the ati driver again. regards martin Am 17.07.2013 07:05, schrieb Martin Wolf: thank you for the quick response alex, but i still need your help ;) i cloned both git trees (http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg00432.html) that was the easy part for me (it boots like a charm ...) ... then i built the qemu tree and found out that it is just 1.4.50 and something was missing so qemu would not start up ... would you be so kind alex and supply me with the patches you meant yesterday i would need for qemu? ty in advance Am 16.07.2013 16:25, schrieb Alex Williamson: On Tue, 2013-07-16 at 14:35 +0200, Martin Wolf wrote: Early 2012 i tested the old vga passthrough capabilities of KVM and was partly successful. now with the new vfio driver i tried again according to alex's hints and this guide: https://bbs.archlinux.org/viewtopic.php?id=162768 since im primarily using ubuntu i used the daily build of saucy. it ships qemu 1.5 and seabios 1.7.3 so the requirements are met. according to the guide i prepared the vga card (amd 7870) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.10.0-2-generic root=UUID=26fed560-a972-499d-ab14-7fec6439fd3d ro intel_iommu=on pci-stub.ids=1002:6818,1002:aab0 quiet splash vt.handoff=7 [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.10.0-2-generic root=UUID=26fed560-a972-499d-ab14-7fec6439fd3d ro intel_iommu=on pci-stub.ids=1002:6818,1002:aab0 quiet splash vt.handoff=7 [0.569977] pci-stub: add 1002:6818 sub=: cls=/ [0.569987] pci-stub :01:00.0: claimed by stub [0.569994] pci-stub: add 1002:AAB0 sub=: cls=/ [0.569998] pci-stub :01:00.1: claimed by stub then did this just to be sure: echo options vfio_iommu_type1 allow_unsafe_interrupts=1 /etc/modprobe.d/vfio_iommu_type1.conf (or was that wrong?) im using a z87 haswell mainboard Hopefully not needed, only use this option if you need to. vfio will print an error to dmesg and qemu will fail to start if you need it. after that i binded the two devices to vfio-pci with: vfio-bind :01:00.0 :01:00.1 (the script in the guide) afterwards i was able to start the kvm with qemu-system-x86_64 -enable-kvm -M q35 -m 8192 -cpu host \ -smp 8,sockets=1,cores=4,threads=8 \ -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 \ -device ahci,bus=pcie.0,id=ahci \ -drive file=/home/martin/windows.img,if=none,id=disk,format=raw -device virtio-blk-pci,drive=disk \ -drive file=/home/martin/X17-59885.iso,id=isocd -device ide-cd,bus=ahci.0,drive=isocd \ -net nic,model=virtio \ -net user \ -usb -usbdevice host:1532:000c \ -drive file=/home/martin/Downloads/virtio-win-0.1-59.iso,id=isocd1 -device ide-cd,bus=ahci.1,drive=isocd1 to my surprise i instantly got the windows installation running installed the virtio drivers for nic and storage and had 15 mins later a working win7 installation. now i installed the amd driver (13.4) and rebooted. i got a bluescreen. similar to my old expiriences so i thought do a clean host reboot and try again. but still the same. so i tried to load the bios.rom for the card (found it on techpowerup) again no luck. maybe someone knows a hint? I think most of the folks using the guide you reference are using my vfio-vga-reset branches of qemu kernel (or patches extracted from them). These add an important step for reproducibility, by being able to reset the bus for the graphics card, giving us a way to reset the device. The other thing in the qemu branch are improved quirks. I've just posted these to qemu-devel and plan to get them pulled for 1.6. Note that for ATI/AMD cards, a critical quirks is intercepting the byte at I/O port address 0x3c3. Without this, the VGA BIOS can't bootstrap itself. The vfio-vga-reset branch has a conditional replacement of this, which doesn't seem to work for everyone. I believe the version I posted to qemu-devel yesterday is a better
Re: vga passthrough // vfio // qemu bridge
Yes, thats my error, sorry for causing extra work... i compiled qemu 1.5.1 now with your patchset. but now i qemu shuts down with this error when windows tries to start: qemu-system-x86_64: hw/usb/core.c:413: usb_handle_packet: Zusicherung »p-ep-type != 3 || (dev-flags (1 USB_DEV_FLAG_IS_HOST))« nicht erfüllt. Am 19.07.2013 16:21, schrieb Alex Williamson: On Fri, 2013-07-19 at 12:41 +0200, Martin Wolf wrote: I just started over because of several small glitches that came from constantly reinstalling qemu. im still using saucy 13.10 alpha for the tests with a modified ubuntu kernel (with alex patch) and since i found out that the patches of alex are now pulled into qemu 1.6 i chose to use qemu git. Correction, the VGA quirks are pulled in, but the bus reset stuff is not. after some perparation (apt-get build-depends qemu) i configured qemu with (./configure --target-list=x86_64-softmmu) and installed it to /usr/local. when i wanted to start qemu-system-x64 the screen connected to the 7870 still did not start (the usb devices were instantly pulled so something must have happened). then i tried the seabios supplied by ubuntu(1.7.3), then the screen went on , but after the driver installation i got a bluescreen connected to the ati driver again. QEMU hasn't updated the BIOS yet, so the VGA route initialization is still missing. Updating seabios fixed that, but you're still missing the bus reset parts of the vfio-vga-reset qemu branch, so the card may be in a bad state when the drivers load. Thanks, Alex Am 17.07.2013 07:05, schrieb Martin Wolf: thank you for the quick response alex, but i still need your help ;) i cloned both git trees (http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg00432.html) that was the easy part for me (it boots like a charm ...) ... then i built the qemu tree and found out that it is just 1.4.50 and something was missing so qemu would not start up ... would you be so kind alex and supply me with the patches you meant yesterday i would need for qemu? ty in advance Am 16.07.2013 16:25, schrieb Alex Williamson: On Tue, 2013-07-16 at 14:35 +0200, Martin Wolf wrote: Early 2012 i tested the old vga passthrough capabilities of KVM and was partly successful. now with the new vfio driver i tried again according to alex's hints and this guide: https://bbs.archlinux.org/viewtopic.php?id=162768 since im primarily using ubuntu i used the daily build of saucy. it ships qemu 1.5 and seabios 1.7.3 so the requirements are met. according to the guide i prepared the vga card (amd 7870) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.10.0-2-generic root=UUID=26fed560-a972-499d-ab14-7fec6439fd3d ro intel_iommu=on pci-stub.ids=1002:6818,1002:aab0 quiet splash vt.handoff=7 [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.10.0-2-generic root=UUID=26fed560-a972-499d-ab14-7fec6439fd3d ro intel_iommu=on pci-stub.ids=1002:6818,1002:aab0 quiet splash vt.handoff=7 [0.569977] pci-stub: add 1002:6818 sub=: cls=/ [0.569987] pci-stub :01:00.0: claimed by stub [0.569994] pci-stub: add 1002:AAB0 sub=: cls=/ [0.569998] pci-stub :01:00.1: claimed by stub then did this just to be sure: echo options vfio_iommu_type1 allow_unsafe_interrupts=1 /etc/modprobe.d/vfio_iommu_type1.conf (or was that wrong?) im using a z87 haswell mainboard Hopefully not needed, only use this option if you need to. vfio will print an error to dmesg and qemu will fail to start if you need it. after that i binded the two devices to vfio-pci with: vfio-bind :01:00.0 :01:00.1 (the script in the guide) afterwards i was able to start the kvm with qemu-system-x86_64 -enable-kvm -M q35 -m 8192 -cpu host \ -smp 8,sockets=1,cores=4,threads=8 \ -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 \ -device ahci,bus=pcie.0,id=ahci \ -drive file=/home/martin/windows.img,if=none,id=disk,format=raw -device virtio-blk-pci,drive=disk \ -drive file=/home/martin/X17-59885.iso,id=isocd -device ide-cd,bus=ahci.0,drive=isocd \ -net nic,model=virtio \ -net user \ -usb -usbdevice host:1532:000c \ -drive file=/home/martin/Downloads/virtio-win-0.1-59.iso,id=isocd1 -device ide-cd,bus=ahci.1,drive=isocd1 to my surprise i instantly got the windows installation running installed the virtio drivers for nic and storage and had 15 mins later a working win7 installation. now i installed the amd driver (13.4) and rebooted. i got a bluescreen. similar to my old expiriences so i thought do a clean host reboot and try again. but still the same. so i tried to load the bios.rom for the card (found it on techpowerup) again no luck. maybe
vga passthrough // vfio // qemu bridge
Early 2012 i tested the old vga passthrough capabilities of KVM and was partly successful. now with the new vfio driver i tried again according to alex's hints and this guide: https://bbs.archlinux.org/viewtopic.php?id=162768 since im primarily using ubuntu i used the daily build of saucy. it ships qemu 1.5 and seabios 1.7.3 so the requirements are met. according to the guide i prepared the vga card (amd 7870) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.10.0-2-generic root=UUID=26fed560-a972-499d-ab14-7fec6439fd3d ro intel_iommu=on pci-stub.ids=1002:6818,1002:aab0 quiet splash vt.handoff=7 [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.10.0-2-generic root=UUID=26fed560-a972-499d-ab14-7fec6439fd3d ro intel_iommu=on pci-stub.ids=1002:6818,1002:aab0 quiet splash vt.handoff=7 [0.569977] pci-stub: add 1002:6818 sub=: cls=/ [0.569987] pci-stub :01:00.0: claimed by stub [0.569994] pci-stub: add 1002:AAB0 sub=: cls=/ [0.569998] pci-stub :01:00.1: claimed by stub then did this just to be sure: echo options vfio_iommu_type1 allow_unsafe_interrupts=1 /etc/modprobe.d/vfio_iommu_type1.conf (or was that wrong?) im using a z87 haswell mainboard after that i binded the two devices to vfio-pci with: vfio-bind :01:00.0 :01:00.1 (the script in the guide) afterwards i was able to start the kvm with qemu-system-x86_64 -enable-kvm -M q35 -m 8192 -cpu host \ -smp 8,sockets=1,cores=4,threads=8 \ -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 \ -device ahci,bus=pcie.0,id=ahci \ -drive file=/home/martin/windows.img,if=none,id=disk,format=raw -device virtio-blk-pci,drive=disk \ -drive file=/home/martin/X17-59885.iso,id=isocd -device ide-cd,bus=ahci.0,drive=isocd \ -net nic,model=virtio \ -net user \ -usb -usbdevice host:1532:000c \ -drive file=/home/martin/Downloads/virtio-win-0.1-59.iso,id=isocd1 -device ide-cd,bus=ahci.1,drive=isocd1 to my surprise i instantly got the windows installation running installed the virtio drivers for nic and storage and had 15 mins later a working win7 installation. now i installed the amd driver (13.4) and rebooted. i got a bluescreen. similar to my old expiriences so i thought do a clean host reboot and try again. but still the same. so i tried to load the bios.rom for the card (found it on techpowerup) again no luck. maybe someone knows a hint? --- about qemu bridge i tried to set up a bridge with the config but qemu always told me that qemu-bridge-helper is not present. all i found out that it propably got removed from the package because of the lack of control over the tap devices. now my question how can i still bridge the vm into my network without that helper? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga passthrough // vfio // qemu bridge
thank you for the quick response alex, but i still need your help ;) i cloned both git trees (http://lists.gnu.org/archive/html/qemu-devel/2013-05/msg00432.html) that was the easy part for me (it boots like a charm ...) ... then i built the qemu tree and found out that it is just 1.4.50 and something was missing so qemu would not start up ... would you be so kind alex and supply me with the patches you meant yesterday i would need for qemu? ty in advance Am 16.07.2013 16:25, schrieb Alex Williamson: On Tue, 2013-07-16 at 14:35 +0200, Martin Wolf wrote: Early 2012 i tested the old vga passthrough capabilities of KVM and was partly successful. now with the new vfio driver i tried again according to alex's hints and this guide: https://bbs.archlinux.org/viewtopic.php?id=162768 since im primarily using ubuntu i used the daily build of saucy. it ships qemu 1.5 and seabios 1.7.3 so the requirements are met. according to the guide i prepared the vga card (amd 7870) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.10.0-2-generic root=UUID=26fed560-a972-499d-ab14-7fec6439fd3d ro intel_iommu=on pci-stub.ids=1002:6818,1002:aab0 quiet splash vt.handoff=7 [0.00] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.10.0-2-generic root=UUID=26fed560-a972-499d-ab14-7fec6439fd3d ro intel_iommu=on pci-stub.ids=1002:6818,1002:aab0 quiet splash vt.handoff=7 [0.569977] pci-stub: add 1002:6818 sub=: cls=/ [0.569987] pci-stub :01:00.0: claimed by stub [0.569994] pci-stub: add 1002:AAB0 sub=: cls=/ [0.569998] pci-stub :01:00.1: claimed by stub then did this just to be sure: echo options vfio_iommu_type1 allow_unsafe_interrupts=1 /etc/modprobe.d/vfio_iommu_type1.conf (or was that wrong?) im using a z87 haswell mainboard Hopefully not needed, only use this option if you need to. vfio will print an error to dmesg and qemu will fail to start if you need it. after that i binded the two devices to vfio-pci with: vfio-bind :01:00.0 :01:00.1 (the script in the guide) afterwards i was able to start the kvm with qemu-system-x86_64 -enable-kvm -M q35 -m 8192 -cpu host \ -smp 8,sockets=1,cores=4,threads=8 \ -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 \ -device ahci,bus=pcie.0,id=ahci \ -drive file=/home/martin/windows.img,if=none,id=disk,format=raw -device virtio-blk-pci,drive=disk \ -drive file=/home/martin/X17-59885.iso,id=isocd -device ide-cd,bus=ahci.0,drive=isocd \ -net nic,model=virtio \ -net user \ -usb -usbdevice host:1532:000c \ -drive file=/home/martin/Downloads/virtio-win-0.1-59.iso,id=isocd1 -device ide-cd,bus=ahci.1,drive=isocd1 to my surprise i instantly got the windows installation running installed the virtio drivers for nic and storage and had 15 mins later a working win7 installation. now i installed the amd driver (13.4) and rebooted. i got a bluescreen. similar to my old expiriences so i thought do a clean host reboot and try again. but still the same. so i tried to load the bios.rom for the card (found it on techpowerup) again no luck. maybe someone knows a hint? I think most of the folks using the guide you reference are using my vfio-vga-reset branches of qemu kernel (or patches extracted from them). These add an important step for reproducibility, by being able to reset the bus for the graphics card, giving us a way to reset the device. The other thing in the qemu branch are improved quirks. I've just posted these to qemu-devel and plan to get them pulled for 1.6. Note that for ATI/AMD cards, a critical quirks is intercepting the byte at I/O port address 0x3c3. Without this, the VGA BIOS can't bootstrap itself. The vfio-vga-reset branch has a conditional replacement of this, which doesn't seem to work for everyone. I believe the version I posted to qemu-devel yesterday is a better implementation of that quirk. --- about qemu bridge i tried to set up a bridge with the config but qemu always told me that qemu-bridge-helper is not present. all i found out that it propably got removed from the package because of the lack of control over the tap devices. now my question how can i still bridge the vm into my network without that helper? I don't know what qemu-bridge-helper is/was, but you're probably better off asking bridge questions in a separate thread instead of buried here. Thanks, Alex -- Adiumentum GmbH Gf. Martin Wolf Banderbacherstraße 76 90513 Zirndorf 0911 / 9601470 mw...@adiumentum.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga passthrough // questions about pci passthrough
Hello, would a Memory Dump from inside the VM help solving the BSOD, or is that pointless? Thank you for your patience and help ;) Am 28.09.2012 18:29, schrieb Jan Kiszka: On 2012-09-28 17:50, Alex Williamson wrote: On Fri, 2012-09-28 at 10:12 +0200, Jan Kiszka wrote: On 2012-09-27 21:18, Alex Williamson wrote: On Thu, 2012-09-27 at 20:43 +0200, Martin Wolf wrote: thank you for the information. i will try what you mentioned... do you have some additional information about rebooting a VM with a passed through videocard? (amd / ati 7870) I don't. Is the bsod on reboot only or does it also happen on shutdown? There's a slim chance it could be traced by enabling debug in the pci-assign driver and analyzing what the guest driver is trying to do. I'm hoping that q35 chipset support might resolve some issues with vga assignment as it exposes a topology that looks a bit more like one that a driver would expect on physical hardware. Thanks, From our attempts to get more working than what NVIDIA Quadro cards support officially, my own experiments with q35 in this context and our discussions with NVIDIA, I'm pretty skeptical that this chipset will make a difference here. Most problems are due to those non-standard side channels to configure the hardware, memory mappings etc. And getting this working requires either cooperation of the vendor or *a lot* of reverse engineering. I heard from an nvidia guy that the driver behaves differently depending on whether it finds an upstream express port, so we're probably causing ourselves more problems if it's trying to run in AGP mode. May be a point for the low- to mid-range cards. It does not apply to the virtualization-ready Quadro series according to our information back then. There was also a lot of FUD in Xen (maybe justified) around how the BIOS determines the memory ranges and whether it bypasses the PCI BARs and gets them directly. That means some cards may require identity mapping to work. It seems like the very high-end cards are possibly fixing this, but they're far more expensive than I can justify. Thanks, Yes, that is what makes them virtualization ready. But they also come with limitations. So far, you can't pass-through a primary card or use it for early boot messages of the guest as the BIOS is not ready for that - without identity mapping or even more. Jan -- Adiumentum GmbH Gf. Martin Wolf Banderbacherstraße 76 90513 Zirndorf 0911 / 9601470 mw...@adiumentum.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga passthrough // questions about pci passthrough
well my first tests with the vga rom were useless because of apparmor rules i guess now i placed the vga.rom in /usr/share/qemu ... well the error is gone now but no changes ;) so i added the bar parameter but it also made no difference :( are you interested in the windows memory dump from the bsod? another thing, after i ran some benchmarks after a fresh reboot on win7 i wanted to measure some values of the 7870 so i started gpu-z ( http://www.techpowerup.com/gpuz/ ) then almost immediately the vm froze i found one log entry in one of the libvirt log files: kvm: /build/buildd/qemu-kvm-1.2.0+noroms/exec.c:2255: register_subpage: Assertion `existing-mr-subpage || existing-mr == io_mem_unassigned' failed. maybe you know what this is about. thanks again for your patience and help ;) Am 28.09.2012 10:12, schrieb Jan Kiszka: On 2012-09-27 21:18, Alex Williamson wrote: On Thu, 2012-09-27 at 20:43 +0200, Martin Wolf wrote: thank you for the information. i will try what you mentioned... do you have some additional information about rebooting a VM with a passed through videocard? (amd / ati 7870) I don't. Is the bsod on reboot only or does it also happen on shutdown? There's a slim chance it could be traced by enabling debug in the pci-assign driver and analyzing what the guest driver is trying to do. I'm hoping that q35 chipset support might resolve some issues with vga assignment as it exposes a topology that looks a bit more like one that a driver would expect on physical hardware. Thanks, From our attempts to get more working than what NVIDIA Quadro cards support officially, my own experiments with q35 in this context and our discussions with NVIDIA, I'm pretty skeptical that this chipset will make a difference here. Most problems are due to those non-standard side channels to configure the hardware, memory mappings etc. And getting this working requires either cooperation of the vendor or *a lot* of reverse engineering. Jan -- Adiumentum GmbH Gf. Martin Wolf Banderbacherstraße 76 90513 Zirndorf 0911 / 9601470 mw...@adiumentum.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga passthrough // questions about pci passthrough
i waited 2 months to get a more stable ubuntu 12.10 now that i dont get crashes every 5 minutes im going to test again. as you remember my two only problems are first the reboot issue of the gues os and second the xonar 2 d2x audio card. but first i would like to work on the reboot issue since i guess this is far more important. when i read the faq i found that one problem could be the VBIOS ROM access i tried -device pci-assign,...,romfile=... but have not found any output or change. is there some documentation of the romfile command to generate usable output? for testing i downloaded the bios of my videocard from techpowerup. they have a huge database and my card and biosrevision is listed. was that ok or do i have to retrieve the bios from inside the vm? thank you in advance Am 19.07.2012 18:16, schrieb Alex Williamson: On Thu, 2012-07-19 at 16:54 +0200, Martin Wolf wrote: i tried now the alpha of ubuntu 12.10 that includes qemu-kvm 1.1 and a 3.5 kernel version. the msr problem is gone now, i was able to select sandybridge as cpu topology, this removed the MSR error messages. thats the positive part... unfortunately i had no success with the other topics (rebootability and the soundcard) rebootability: the guest vm still crashes with a page fault bluescreen soundcard: it would be really nice if someone would be able to give me some advise how to debug this problem. If kernel/qemu-kvm update didn't help, then the device probably doesn't support the interrupt disable mechanism that allows shared interrupts. Therefore the device needs to be on an exclusive interrupt on the host. Look in /proc/interrupts and see what else is on the same interrupt line. Your output below indicates the device is on IRQ 11. Sometimes moving the device to a different physical slot will change the IRQ and give you an exclusive interrupt, otherwise you need to find the devices sharing that interrupt line and disable them by attaching the device to pci-stub. Thanks, Alex Am 18.07.2012 16:23, schrieb Alex Williamson: On Wed, 2012-07-18 at 14:37 +0200, Martin Wolf wrote: soundcard logs added On 18.07.2012 14:08, Martin Wolf wrote: On 18.07.2012 11:26, Jan Kiszka wrote: On 2012-07-18 07:45, Martin Wolf wrote: Hello, i was able to passthrough an AMD 7870 videocard to my win7 guest machine. Would you add it to http://www.linux-kvm.org/page/VGA_device_assignment? sure, i will prepare something my host is ubuntu 12.04 with stock kernel. my system contains: dq67sw q67 mainboard i5-2400s cpu sapphire 7870 amd videocard xonar d2x (problems to passthrough) for full functionality i just needed two options - kernel : iommu=on - kvm module: ignore_msrs=1 (if i would not set it the guest os would crash with a bluescreen) Can you report (= kernel log) which MSRs are unknown to KVM? Jul 18 14:03:33 kvm-xen kernel: [ 437.309931] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522724] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522733] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522736] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522752] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522755] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522821] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522823] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522834] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522840] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522842] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522865] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522867] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522921] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523005] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523081] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523175] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523248] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.52] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523430] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop i hope thats the info you need, i booted it with ignore_msrs=1 since if i dont do that i get less output. (do you need it without the option?) the unigine benchmark ran flawlessly also the benchmark
Re: vga passthrough // questions about pci passthrough
thank you for the information. i will try what you mentioned... do you have some additional information about rebooting a VM with a passed through videocard? (amd / ati 7870) thanks in advance Am 27.09.2012 19:56, schrieb Alex Williamson: On Thu, 2012-09-27 at 13:19 +0200, Martin Wolf wrote: i waited 2 months to get a more stable ubuntu 12.10 now that i dont get crashes every 5 minutes im going to test again. as you remember my two only problems are first the reboot issue of the gues os and second the xonar 2 d2x audio card. but first i would like to work on the reboot issue since i guess this is far more important. when i read the faq i found that one problem could be the VBIOS ROM access i tried -device pci-assign,...,romfile=... but have not found any output or change. is there some documentation of the romfile command to generate usable output? If you can read the rom from the host, this probably isn't adding anything. You can test this by finding the rom in /sys (find /sys -name rom), match it up to the PCI device you're assigning. Then do: # echo 1 rom # xxd rom | head #echo 0 rom If you get something out that starts with 55aa then qemu will be able to read the rom directly. If you're replacing the rom with the romfile= option, you can boot a linux guest, do the same as above to read the rom from the guest, save it to a file and compare md5sum of what the guest sees to the file provided. If qemu is reading the rom on the device correctly, it's no surprise that providing one doesn't make any difference. for testing i downloaded the bios of my videocard from techpowerup. they have a huge database and my card and biosrevision is listed. was that ok or do i have to retrieve the bios from inside the vm? Thanks for mentioning that. From other reports I've seen, it looks like nvidia cards are the troublesome ones for being able to read the BIOS from the host. Thanks, Alex thank you in advance Am 19.07.2012 18:16, schrieb Alex Williamson: On Thu, 2012-07-19 at 16:54 +0200, Martin Wolf wrote: i tried now the alpha of ubuntu 12.10 that includes qemu-kvm 1.1 and a 3.5 kernel version. the msr problem is gone now, i was able to select sandybridge as cpu topology, this removed the MSR error messages. thats the positive part... unfortunately i had no success with the other topics (rebootability and the soundcard) rebootability: the guest vm still crashes with a page fault bluescreen soundcard: it would be really nice if someone would be able to give me some advise how to debug this problem. If kernel/qemu-kvm update didn't help, then the device probably doesn't support the interrupt disable mechanism that allows shared interrupts. Therefore the device needs to be on an exclusive interrupt on the host. Look in /proc/interrupts and see what else is on the same interrupt line. Your output below indicates the device is on IRQ 11. Sometimes moving the device to a different physical slot will change the IRQ and give you an exclusive interrupt, otherwise you need to find the devices sharing that interrupt line and disable them by attaching the device to pci-stub. Thanks, Alex Am 18.07.2012 16:23, schrieb Alex Williamson: On Wed, 2012-07-18 at 14:37 +0200, Martin Wolf wrote: soundcard logs added On 18.07.2012 14:08, Martin Wolf wrote: On 18.07.2012 11:26, Jan Kiszka wrote: On 2012-07-18 07:45, Martin Wolf wrote: Hello, i was able to passthrough an AMD 7870 videocard to my win7 guest machine. Would you add it to http://www.linux-kvm.org/page/VGA_device_assignment? sure, i will prepare something my host is ubuntu 12.04 with stock kernel. my system contains: dq67sw q67 mainboard i5-2400s cpu sapphire 7870 amd videocard xonar d2x (problems to passthrough) for full functionality i just needed two options - kernel : iommu=on - kvm module: ignore_msrs=1 (if i would not set it the guest os would crash with a bluescreen) Can you report (= kernel log) which MSRs are unknown to KVM? Jul 18 14:03:33 kvm-xen kernel: [ 437.309931] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522724] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522733] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522736] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522752] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522755] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522821] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522823] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522834] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522840] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522842] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18
Re: vga passthrough // questions about pci passthrough
when will that support be implemented? how do i enable debug support for the pci-assign driver? Am 27.09.2012 21:18, schrieb Alex Williamson: On Thu, 2012-09-27 at 20:43 +0200, Martin Wolf wrote: thank you for the information. i will try what you mentioned... do you have some additional information about rebooting a VM with a passed through videocard? (amd / ati 7870) I don't. Is the bsod on reboot only or does it also happen on shutdown? There's a slim chance it could be traced by enabling debug in the pci-assign driver and analyzing what the guest driver is trying to do. I'm hoping that q35 chipset support might resolve some issues with vga assignment as it exposes a topology that looks a bit more like one that a driver would expect on physical hardware. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Adiumentum GmbH Gf. Martin Wolf Banderbacherstraße 76 90513 Zirndorf 0911 / 9601470 mw...@adiumentum.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga passthrough // questions about pci passthrough
about your question if the bsod also happens on shutdown, i have to deny it. it just happens after an msi message in kernel log on rebooting the vm. (but the msi message is also there on initial boot where the system works perfectly) in my oppinion at the moment when the video driver is loaded. Am 27.09.2012 22:46, schrieb Alex Williamson: On Thu, 2012-09-27 at 21:37 +0200, Martin Wolf wrote: when will that support be implemented? how do i enable debug support for the pci-assign driver? I believe the target is qemu 1.3 for q35. Debug is enabled by uncommenting the DEVICE_ASSIGNMENT_DEBUG define in hw/kvm/pci-assign.c (or hw/device-assignment.c on qemu-kvm in an older tree) and rebuilding. Thanks, Alex Am 27.09.2012 21:18, schrieb Alex Williamson: On Thu, 2012-09-27 at 20:43 +0200, Martin Wolf wrote: thank you for the information. i will try what you mentioned... do you have some additional information about rebooting a VM with a passed through videocard? (amd / ati 7870) I don't. Is the bsod on reboot only or does it also happen on shutdown? There's a slim chance it could be traced by enabling debug in the pci-assign driver and analyzing what the guest driver is trying to do. I'm hoping that q35 chipset support might resolve some issues with vga assignment as it exposes a topology that looks a bit more like one that a driver would expect on physical hardware. Thanks, Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Adiumentum GmbH Gf. Martin Wolf Banderbacherstraße 76 90513 Zirndorf 0911 / 9601470 mw...@adiumentum.com -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga passthrough // questions about pci passthrough
i tried now the alpha of ubuntu 12.10 that includes qemu-kvm 1.1 and a 3.5 kernel version. the msr problem is gone now, i was able to select sandybridge as cpu topology, this removed the MSR error messages. thats the positive part... unfortunately i had no success with the other topics (rebootability and the soundcard) rebootability: the guest vm still crashes with a page fault bluescreen soundcard: it would be really nice if someone would be able to give me some advise how to debug this problem. thank you for your help Am 18.07.2012 16:23, schrieb Alex Williamson: On Wed, 2012-07-18 at 14:37 +0200, Martin Wolf wrote: soundcard logs added On 18.07.2012 14:08, Martin Wolf wrote: On 18.07.2012 11:26, Jan Kiszka wrote: On 2012-07-18 07:45, Martin Wolf wrote: Hello, i was able to passthrough an AMD 7870 videocard to my win7 guest machine. Would you add it to http://www.linux-kvm.org/page/VGA_device_assignment? sure, i will prepare something my host is ubuntu 12.04 with stock kernel. my system contains: dq67sw q67 mainboard i5-2400s cpu sapphire 7870 amd videocard xonar d2x (problems to passthrough) for full functionality i just needed two options - kernel : iommu=on - kvm module: ignore_msrs=1 (if i would not set it the guest os would crash with a bluescreen) Can you report (= kernel log) which MSRs are unknown to KVM? Jul 18 14:03:33 kvm-xen kernel: [ 437.309931] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522724] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522733] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522736] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522752] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522755] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522821] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522823] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522834] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522840] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522842] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522865] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522867] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522921] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523005] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523081] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523175] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523248] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.52] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523430] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop i hope thats the info you need, i booted it with ignore_msrs=1 since if i dont do that i get less output. (do you need it without the option?) the unigine benchmark ran flawlessly also the benchmark included in windows gave my videocard similar values (7.7) comparable with my native win7 (7.9) now to my questions... 1. is it possible to reset the videocard properly to be able to reboot the vm? Which versions of kernel and qemu-kvm are involved via your distro? Can you retry with latest Linux (3.5-rcX) / lastest qemu-kvm? Maybe something got fixed meanwhile. In general, there are many adapters that require special procedures to perform resets. This one may fall into that category as well. i will do a test today. 2.the xonar d2x is a very nice audio card, it would be very handy to be able to use it in the vm. in my oppinion the card is a d2 with a pci-e to pci bridge. i tried to passthrough the card alone and with the pci-bridge that was shown though lspci, but i had no success. maybe you guys here have an idea on that topic? Any further details about the error? Does the adapter work with a Linux guest or provide more information that way? Jan 02:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=02, secondary=03, subordinate=03, sec-latency=32
Re: vga passthrough // questions about pci passthrough
On 18.07.2012 11:26, Jan Kiszka wrote: On 2012-07-18 07:45, Martin Wolf wrote: Hello, i was able to passthrough an AMD 7870 videocard to my win7 guest machine. Would you add it to http://www.linux-kvm.org/page/VGA_device_assignment? sure, i will prepare something my host is ubuntu 12.04 with stock kernel. my system contains: dq67sw q67 mainboard i5-2400s cpu sapphire 7870 amd videocard xonar d2x (problems to passthrough) for full functionality i just needed two options - kernel : iommu=on - kvm module: ignore_msrs=1 (if i would not set it the guest os would crash with a bluescreen) Can you report (= kernel log) which MSRs are unknown to KVM? Jul 18 14:03:33 kvm-xen kernel: [ 437.309931] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522724] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522733] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522736] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522752] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522755] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522821] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522823] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522834] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522840] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522842] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522865] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522867] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522921] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523005] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523081] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523175] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523248] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.52] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523430] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop i hope thats the info you need, i booted it with ignore_msrs=1 since if i dont do that i get less output. (do you need it without the option?) the unigine benchmark ran flawlessly also the benchmark included in windows gave my videocard similar values (7.7) comparable with my native win7 (7.9) now to my questions... 1. is it possible to reset the videocard properly to be able to reboot the vm? Which versions of kernel and qemu-kvm are involved via your distro? Can you retry with latest Linux (3.5-rcX) / lastest qemu-kvm? Maybe something got fixed meanwhile. In general, there are many adapters that require special procedures to perform resets. This one may fall into that category as well. i will do a test today. 2.the xonar d2x is a very nice audio card, it would be very handy to be able to use it in the vm. in my oppinion the card is a d2 with a pci-e to pci bridge. i tried to passthrough the card alone and with the pci-bridge that was shown though lspci, but i had no success. maybe you guys here have an idea on that topic? Any further details about the error? Does the adapter work with a Linux guest or provide more information that way? Jan i will also add info here later -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: vga passthrough // questions about pci passthrough
soundcard logs added On 18.07.2012 14:08, Martin Wolf wrote: On 18.07.2012 11:26, Jan Kiszka wrote: On 2012-07-18 07:45, Martin Wolf wrote: Hello, i was able to passthrough an AMD 7870 videocard to my win7 guest machine. Would you add it to http://www.linux-kvm.org/page/VGA_device_assignment? sure, i will prepare something my host is ubuntu 12.04 with stock kernel. my system contains: dq67sw q67 mainboard i5-2400s cpu sapphire 7870 amd videocard xonar d2x (problems to passthrough) for full functionality i just needed two options - kernel : iommu=on - kvm module: ignore_msrs=1 (if i would not set it the guest os would crash with a bluescreen) Can you report (= kernel log) which MSRs are unknown to KVM? Jul 18 14:03:33 kvm-xen kernel: [ 437.309931] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522724] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522733] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522736] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522752] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522755] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522821] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522823] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522834] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.522840] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522842] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522865] kvm: 3347: cpu1 ignored rdmsr: 0x1c9 Jul 18 14:03:33 kvm-xen kernel: [ 437.522867] kvm: 3347: cpu1 ignored rdmsr: 0x60 Jul 18 14:03:33 kvm-xen kernel: [ 437.522921] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523005] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523081] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523175] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523248] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.52] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop Jul 18 14:03:33 kvm-xen kernel: [ 437.523430] kvm: 3347: cpu1 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x1, nop i hope thats the info you need, i booted it with ignore_msrs=1 since if i dont do that i get less output. (do you need it without the option?) the unigine benchmark ran flawlessly also the benchmark included in windows gave my videocard similar values (7.7) comparable with my native win7 (7.9) now to my questions... 1. is it possible to reset the videocard properly to be able to reboot the vm? Which versions of kernel and qemu-kvm are involved via your distro? Can you retry with latest Linux (3.5-rcX) / lastest qemu-kvm? Maybe something got fixed meanwhile. In general, there are many adapters that require special procedures to perform resets. This one may fall into that category as well. i will do a test today. 2.the xonar d2x is a very nice audio card, it would be very handy to be able to use it in the vm. in my oppinion the card is a d2 with a pci-e to pci bridge. i tried to passthrough the card alone and with the pci-bridge that was shown though lspci, but i had no success. maybe you guys here have an idea on that topic? Any further details about the error? Does the adapter work with a Linux guest or provide more information that way? Jan 02:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=02, secondary=03, subordinate=03, sec-latency=32 I/O behind bridge: d000-dfff Memory behind bridge: fff0-000f Prefetchable memory behind bridge: fff0-000f Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pci-stub Kernel modules: shpchp 03:04.0 Multimedia audio controller: C-Media Electronics Inc CMI8788 [Oxygen HD Audio] Subsystem: ASUSTeK
vga passthrough // questions about pci passthrough
Hello, i was able to passthrough an AMD 7870 videocard to my win7 guest machine. my host is ubuntu 12.04 with stock kernel. my system contains: dq67sw q67 mainboard i5-2400s cpu sapphire 7870 amd videocard xonar d2x (problems to passthrough) for full functionality i just needed two options - kernel : iommu=on - kvm module: ignore_msrs=1 (if i would not set it the guest os would crash with a bluescreen) the unigine benchmark ran flawlessly also the benchmark included in windows gave my videocard similar values (7.7) comparable with my native win7 (7.9) now to my questions... 1. is it possible to reset the videocard properly to be able to reboot the vm? 2. the xonar d2x is a very nice audio card, it would be very handy to be able to use it in the vm. in my oppinion the card is a d2 with a pci-e to pci bridge. i tried to passthrough the card alone and with the pci-bridge that was shown though lspci, but i had no success. maybe you guys here have an idea on that topic? thank you for you great work ;) -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
