Re: pci device passthrough: Failed to assign irq
> I'm trying to pass a pcie-device into a kvm guest. qemu-kvm is started > by libvirt with this command: [...] > Failed to assign irq for "hostdev0": Operation not permitted > Perhaps you are assigning a device that shares an IRQ with another device? Found out what was causing the issue: Current libvirt seems to drop CAP_SYS_RAWIO before forking qemu-kvm. When I patch libvirt to not drop the capabilities, everything works as expected. So no problem in kvm, sorry for the noise. Kind regards, Gerd -- 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
pci device passthrough: Failed to assign irq
Hi, I'm trying to pass a pcie-device into a kvm guest. qemu-kvm is started by libvirt with this command: LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc-0.12 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name test -uuid cefc7515-c0c2-27fc-8e7e-e0a65f9cb95b -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/test.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -boot c -drive file=/dev/vg_main/test,if=none,id=drive-virtio-disk0,boot=on,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:d0:84:c7,bus=pci.0,addr=0x7 -net tap,fd=59,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:0 -k de -vga cirrus -device pci-assign,host=05:00.0,id=hostdev0,bus=pci.0,addr=0x8 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 It failes with: Failed to assign irq for "hostdev0": Operation not permitted Perhaps you are assigning a device that shares an IRQ with another device? The irq of the device does not seem to be shared: 05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection Subsystem: ASUSTeK Computer Inc. Device 8369 Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at faee (32-bit, non-prefetchable) [size=128K] I/O ports at cc00 [size=32] Memory at faedc000 (32-bit, non-prefetchable) [size=16K] Capabilities: [c8] Power Management version 2 Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [e0] Express Endpoint, MSI 00 Capabilities: [a0] MSI-X: Enable- Count=5 Masked- Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 90-e6-ba-ff-ff-7c-c6-ef Kernel driver in use: pci-stub Kernel modules: e1000e when kvm is not running and the device used as eth0 on host: # cat /proc/interrupts [...] 17: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi sata_sil24 23: 69 0 0 0 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb2 [...] 37: 2 0 0 0 0 0 0 0 PCI-MSI-edge eth0-rx-0 38: 4 0 0 0 0 0 0 0 PCI-MSI-edge eth0-tx-0 39: 1 0 0 0 0 0 0 0 PCI-MSI-edge eth0 [...] qemu-kvm is running as root, selinux is running in permissive mode. So the rights shouldn't be an issue too. The processor is an Intel Core i7-860 on an Asus P7F-E board, chipset is an Intel 3420. Bios is ver 0607, vt-d is enabled in bios setup. This is logged in dmesg, so to me it seems like the system is indeed vt-d capable: [...] ACPI: Core revision 20091214 DMAR: Host address width 36 DMAR: DRHD base: 0x00fed9 flags: 0x1 IOMMU fed9: ver 1:0 cap c90780106f0462 ecap f020e3 DMAR: RMRR base: 0x0e4000 end: 0x0e7fff DMAR: RMRR base: 0x00bf7ec000 end: 0x00bf7f DMAR: No ATSR found Setting APIC routing to physical flat ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 CPU0: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz stepping 05 [...] IOMMU 0xfed9: using Queued invalidation IOMMU: Setting RMRR: IOMMU: Setting identity map for device :00:1d.0 [0xbf7ec000 - 0xbf80] IOMMU: Setting identity map for device :00:1a.0 [0xbf7ec000 - 0xbf80] IOMMU: Setting identity map for device :00:1d.0 [0xe4000 - 0xe8000] IOMMU: Setting identity map for device :00:1a.0 [0xe4000 - 0xe8000] IOMMU: Prepare 0-16MiB unity mapping for LPC IOMMU: Setting identity map for device :00:1f.0 [0x0 - 0x100] alloc irq_desc for 29 on node 0 alloc kstat_irqs on node 0 PCI-DMA: Intel(R) Virtualization Technology for Directed I/O Intel PCLMULQDQ-NI instructions are not detected. [...] Kernel is 2.6.33.3-85.fc13.x86_64. I tried qemu-0.12.3-8.fc13 as it came with Fedora 13 beta and qemu-kvm-0.12.4, same results. Any idea whats going wrong or what else I could try? Kind regards, Gerd -- 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: kvm-85 won't boot guests with virtio block device
Hi Pauline, > To follow up on the issues with kvm-85 and libvirt I discovered the > following issue: libvirt detects from the help of qemu which options it can > give to qemu. (in this case obviously /usr/kvm/bin/qemu-system-x86_64 > -help) > > If you look carefully to the output of the -help of qemu from kvm-84 and > kvm-85, you will notice the boot flag to the -drive option has disappeared! > Hence letting libvirt believe it isnt allowed to use it, hence the unable > to boot error. > > A small patch which fixes the problem for me, is attached. thank you very much for discovering this, your patch solved my problems starting kvm-85 with virtio-blk from libvirt. Kind regards, Gerd -- 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: kvm-85: virtio-blk not working
Hi Bernhard, On Friday 24 April 2009 14:56:15 Bernhard Held wrote: > > does not boot, BIOS complains "Boot failed: could not read the boot > > disk": > > > > -drive file=/dev/VolGroup00/testpart,if=virtio,index=0 \ > > Please try with: > -drive file=/dev/VolGroup00/testpart,if=virtio,index=0,boot=on \ That's it! With boot=on it works. Thanks for pointing this out. Was this change intentional? I didn't see it mentioned in the changelog and could not even find the "boot"-parameter in the qemu-kvm manpage. I usually start kvm via libvirt and libvirt doesn't know anything about boot=on, at least not in 0.6.2. I did not have time to try 0.6.3 as it was released just yet. Is there some way in a running qemu to find out if a virtio blockdevice is activated this way? When running "info block" I always get this result if the device has boot=on or not: virtio0: type=hd removable=0 file=/dev/VolGroup00/testpart ro=0 drv=host_device encrypted=0 Kind regards, Gerd -- 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: kvm-85: virtio-blk not working
Hi Andreas, On Thursday 23 April 2009 19:34:31 Andreas Plesner Jacobsen wrote: > On Thu, Apr 23, 2009 at 06:57:45PM +0200, Gerd v. Egidy wrote: > > sorry, I'm not getting that far to make this a problem. I just added the > > second disk (the virtio one) to test if virtio is working when the guest > > is running. > > > > I first tried it with just one virtio disk and no ide ones: it didin't > > boot ("Boot failed: could not read the boot disk"). > > KVM command line, please. works as expected: /usr/bin/qemu-kvm -S -M pc -m 1024 -smp 1 -name test \ -uuid 283d1332-c234-9f28-24cf-8bbcc17b44c1 -monitor pty \ -pidfile/var/run/libvirt/qemu//test.pid -boot c \ -drive file=/dev/VolGroup00/testpart,if=ide,index=0 \ -net nic,macaddr=54:52:00:7c:a5:89,vlan=0,model=virtio -net tap,fd=16,script=,vlan=0,ifname=vnet0 \ -serial pty -parallel none -usb -vnc 127.0.0.1:0 does not boot, BIOS complains "Boot failed: could not read the boot disk": /usr/bin/qemu-kvm -S -M pc -m 1024 -smp 1 -name test \ -uuid 283d1332-c234-9f28-24cf-8bbcc17b44c1 -monitor pty \ -pidfile /var/run/libvirt/qemu//test.pid -boot c \ -drive file=/dev/VolGroup00/testpart,if=virtio,index=0 \ -net nic,macaddr=54:52:00:7c:a5:89,vlan=0,model=virtio \ -net tap,fd=16,script=,vlan=0,ifname=vnet0 \ -serial pty -parallel none -usb -vnc 127.0.0.1:0 Kind regards, Gerd -- 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: kvm-85: virtio-blk not working
Hi Andreas, > > I am (or better libvirt is) starting the guest like this: > > > > -drive file=/dev/VolGroup00/testboot,if=ide,index=0 \ > > -drive file=/dev/VolGroup00/testvirt,if=virtio,index=1 \ > > Both should have index=0 (or no index at all), since the index is > internal to the driver. sorry, I'm not getting that far to make this a problem. I just added the second disk (the virtio one) to test if virtio is working when the guest is running. I first tried it with just one virtio disk and no ide ones: it didin't boot ("Boot failed: could not read the boot disk"). Kind regards, Gerd -- 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: kvm-85 won't boot guests with virtio block device
Hi Bernhard, > After an upgrade from kvm-84 to kvm-85 all my guests won't start > because no boot device could be found. > >> > >> No problem here, my guests run fine with kvm-85 and 2.6.29.1: > >>-drive file="$IMG",format=raw,cache=none > > This is the right example: > -drive file="$IMAGE1",if=virtio,format=raw,cache=none,boot=on Hmm, ok. Now we've got to find out whats different between yours and Alexeys systems where it works and mine and Darius' where it doesnt. > I'm running 32 bit guest on 32 bit host and 32 bit guest on 64 bit host. > Both "big floppies" and images with partition tables work. I tried 32 bit and 64 bit guest on a 64 bit host. So bitness doesn't seem to be the issue. The kvm-modules seem not to be the issue too because Darius wrote he's using the modules from kvm-85 (seems he forgot to cc the list). Any other ideas? Kind regards, Gerd -- 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: kvm-85 won't boot guests with virtio block device
Hi Bernhard, > >> After an upgrade from kvm-84 to kvm-85 all my guests won't start because > >> no boot device could be found. > > No problem here, my guests run fine with kvm-85 and 2.6.29.1: > -drive file="$IMG",format=raw,cache=none Are you sure you are using a virtio blockdevice and not a regular ide one? IIRC, you need to add if=virtio to the -drive parameter to get virtio. Or became virtio the default these days? Kind regards, Gerd -- 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: kvm-85 won't boot guests with virtio block device
Hi Darius, > After an upgrade from kvm-84 to kvm-85 all my guests won't start because > no boot device could be found. [...] > A rollback to kvm-84 OR changing the hdd from vda to ide for the guests > and everything is OK again I'm having the same problem and repored it to the list just some hours ago. Do you use the kvm kernel modules that came with your host kernel or the ones that came with kvm-85? I used the ones that came with my 2.6.29.1 host kernel. Kind regards, Gerd -- 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
kvm-85: virtio-blk not working
Hi, I just tried to upgrade my kvm (from 79) to the new 85. I'm using qemu-kvm- devel with the kvm-modules (and kernel-includes) that came with 2.6.29.1. Qemu-blockdevices and virtio-net work well. But virtio blockdevices are not accessible from within the guest system. Neither can the BIOS boot from them ("Boot failed: could not read the boot disk") nor can the guest-kernel (2.6.29.1 too) see them. I am (or better libvirt is) starting the guest like this: /usr/bin/qemu-kvm -S -M pc -m 1024 -smp 1 -name test \ -uuid 283d1332-c234-9f28-24cf-8bbcc17b44c1 -monitor pty \ -pidfile /var/run/libvirt/qemu//test.pid -boot c \ -drive file=/dev/VolGroup00/testboot,if=ide,index=0 \ -drive file=/dev/VolGroup00/testvirt,if=virtio,index=1 \ -net nic,macaddr=54:52:00:7c:a5:89,vlan=0,model=virtio \ -net tap,fd=17,script=,vlan=0,ifname=vnet0 \ -serial pty -parallel none -usb -vnc 127.0.0.1:0 When booting the guest I get these messages in the host log, but don't know if they are related: kernel: kvm: 3082: cpu0 unhandled wrmsr: 0xc0010117 data 0 kernel: kvm: 3082: cpu0 unhandled rdmsr: 0xc0010117 kernel: kvm: 3082: cpu0 unhandled rdmsr: 0xc0010117 They show up when not using virtio-blk too. Any ideas? Kind regards, Gerd -- 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