On 2013-05-03 16:37, Alex Williamson wrote: > On Fri, 2013-05-03 at 10:35 +0200, Jan Kiszka wrote: >> On 2013-05-03 09:33, Binarus wrote: >>> Hi all, >>> >>> a while ago, I have set up a KVM virtual machine with PCI passthrough. >>> The device which is passed through is an AVM Fritz!card PCI v2.1. >>> >>> This works, but there is a drawback: At that time, KVM was not able to >>> do PCI passthrough for PCI devices with shared interrupt. So I had to >>> find out which other devices were using the same interrupt, and had to >>> inactivate them by handling them over to the PCI stub driver. >>> >>> Then, one day, I have been very excited when I was reading that with >>> kernel 3.4, KVM should be able to do PCI passthrough even if the >>> respective device shares its IRQ with other devices. Thus, two day ago, >>> I took the time, got vanilla kernel 3.9, configured, compiled and >>> installed, and got qemu 1.4.1, configured, compiled and installed. >>> >>> Now, I am disappointed that the passthrough still doesn't work if I >>> leave the other devices active, probably due to a silly error on my >>> side. It still works if I inactivate the other devices which share their >>> IRQ with the AVM card, but that actually was not the goal. >>> >>> Furthermore, the last two sentences on the following page suggest that >>> PCI passthrough of devices with shared IRQs is still not possible: >>> http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM. So >>> there is a contradiction between what has been stated when kernel 3.4 >>> came out and what linux-kvm.org says. >>> >>> Could anybody please tell me if PCI passthrough with shared IRQs is >>> possible or not? Does anybody know why the AVM Fritz!card won't work >>> without inactivating other devices? What mistake could lead to the >>> current situation (passthrough works if other devices are inactivated, >>> and does not work if not)? >> >> The Fritz!CARD is very old and likely not PCI 2.3 compliant. But that is >> required to share legacy interrupts. > > Yep. Binarus, the issue is that shared interrupts require hardware > support to mask the interrupt at the device. This was introduced as > part of the PCI 2.3 standard. If the device does not support this then > exclusive interrupts are still required. > >> Alex, does VFIO provide any convenient diagnostics if INTx sharing is >> possible or not? If not, maybe we should add it at least over there. > > It does not. It's actually easier to test outside of qemu as vfio will > emulate PCI2.3 support. Here's a simple shell script requiring only > sudo and setpci: > > #!/bin/sh > > DESC=$(lspci -s $1) > > if [ "x$DESC" == "x" ]; then > echo "Device $1 not found" > exit 1 > fi > > ORIGCMD=$(printf 0x%04x $(setpci -s $1 COMMAND)) > NEWCMD=$(printf 0x%04x $(( $ORIGCMD ^ 0x400 ))) > setpci -s $1 COMMAND=$NEWCMD > NEWCMD=$(printf 0x%04x $(setpci -s $1 COMMAND)) > > if [ $ORIGCMD == $NEWCMD ]; then > echo "Device $1 does NOT support PCI 2.3 INTx disable" > exit 1 > fi > > setpci -s $1 COMMAND=$ORIGCMD > echo "Device $1 supports PCI 2.3 INTx disable" > Easier for the implementers POV... ;) Well, please push it at least to our wiki page. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- 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
