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.000000] 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.000000] 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=FFFFFFFF:FFFFFFFF >>>>> cls=00000000/00000000 >>>>> [ 0.569987] pci-stub 0000:01:00.0: claimed by stub >>>>> [ 0.569994] pci-stub: add 1002:AAB0 sub=FFFFFFFF:FFFFFFFF >>>>> cls=00000000/00000000 >>>>> [ 0.569998] pci-stub 0000: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 0000:01:00.0 0000: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 mwolf@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html