Re: PCI passthrough (shared IRQ) not working / contradicting information

[Jan Kiszka <jan.kiszka@siemens.com>]

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