Andreas Hartmann wrote:
> On Wed, 6 Jun 2012 10:12:27 +0200
> Andreas Hartmann <[email protected]> wrote:
>
>> On Tue, 05 Jun 2012 18:55:42 +0200
>> Andreas Hartmann <[email protected]> wrote:
>>
>>> Alex Williamson wrote:
>>> [...]
>>>> Yep, I think the previous suggestion about reloading vfio_iommu_type1
>>>> with allow_unsafe_interrupts=1 will solve it.
>>>
>>> Yes! Works now. Success!!!!!
>>>
>>> Works means: Device is seen in VM. I couldn't test it up to now, because
>>> I don't have any driver in the VM for this device.
>>
>> Meanwhile, I enabled the drivers in the VM for the device I passed
>> through. Unfortunately, it doesn't work :-(. I'm getting this entry in
>> messages at the moment, the module rt2800pci is used by hostapd:
>>
>> Jun 6 09:25:02 host kernel: [ 201.895812] irq 21: nobody cared (try
>> booting with the "irqpoll" option)
>> Jun 6 09:25:02 host kernel: [ 201.895819] Pid: 0, comm: swapper/1 Not
>> tainted 3.4.0-next-20120529-16.1-desktop #6
>> Jun 6 09:25:02 host kernel: [ 201.895822] Call Trace:
>> Jun 6 09:25:02 host kernel: [ 201.895836] <IRQ> [<ffffffff810d37a8>]
>> __report_bad_irq+0x38/0xe0
>> Jun 6 09:25:02 host kernel: [ 201.895842] [<ffffffff810d3a6d>]
>> note_interrupt+0x16d/0x220
>> Jun 6 09:25:02 host kernel: [ 201.895849] [<ffffffff810d12d6>]
>> handle_irq_event_percpu+0xc6/0x270
>> Jun 6 09:25:02 host kernel: [ 201.895855] [<ffffffff810d14c9>]
>> handle_irq_event+0x49/0x70
>> Jun 6 09:25:02 host kernel: [ 201.895860] [<ffffffff810d45d2>]
>> handle_fasteoi_irq+0x82/0x130
>> Jun 6 09:25:02 host kernel: [ 201.895865] [<ffffffff81004460>]
>> handle_irq+0x20/0x30
>> Jun 6 09:25:02 host kernel: [ 201.895869] [<ffffffff81004098>]
>> do_IRQ+0x58/0xe0
>> Jun 6 09:25:02 host kernel: [ 201.895876] [<ffffffff815f112a>]
>> common_interrupt+0x6a/0x6a
>> Jun 6 09:25:02 host kernel: [ 201.895907] <EOI> [<ffffffffa0029077>] ?
>> arch_local_irq_enable+0x8/0xd [processor]
>> Jun 6 09:25:02 host kernel: [ 201.895915] [<ffffffff8107a37a>] ?
>> sched_clock_idle_wakeup_event+0x1a/0x20
>> Jun 6 09:25:02 host kernel: [ 201.895929] [<ffffffffa002a046>]
>> acpi_idle_enter_simple+0xd0/0x111 [processor]
>> Jun 6 09:25:02 host kernel: [ 201.895939] [<ffffffff814915f9>]
>> cpuidle_enter+0x19/0x20
>> Jun 6 09:25:02 host kernel: [ 201.895943] [<ffffffff81491d81>]
>> cpuidle_idle_call+0xc1/0x1e0
>> Jun 6 09:25:02 host kernel: [ 201.895949] [<ffffffff8100bd45>]
>> cpu_idle+0x85/0xd0
>> Jun 6 09:25:02 host kernel: [ 201.895955] [<ffffffff815e63d5>]
>> start_secondary+0x8a/0x8c
>> Jun 6 09:25:02 host kernel: [ 201.895958] handlers:
>> Jun 6 09:25:02 host kernel: [ 201.895967] [<ffffffffa0488230>]
>> vfio_intx_handler [vfio_pci] threaded [<ffffffffa04884e0>] vfio_intx_thread
>> [vfio_pci]
>> Jun 6 09:25:02 host kernel: [ 201.895969] Disabling IRQ #21
>>
>> I tried with irqpoll, but this didn't help. BTW: IRQ 21 isn't a shared
>> interrupt! Did I miss an option during kernel configuration?
>
> No device at all here listens for IRQ 21. The WLAN-device is at IRQ 5
> (no shared IRQ)!
To be more precise:
after the bind procedure, the device is at IRQ 5. After starting of
/usr/local/bin/qemu-system-x86_64, it's at 21.
>
> [...]
>
>> lspci -vs7
>> 06:07.0 Network controller: Ralink corp. RT2800 802.11n PCI
>> Subsystem: Linksys Device 0067
>> Flags: bus master, slow devsel, latency 32, IRQ 5
>> Memory at fd8e0000 (32-bit, non-prefetchable) [size=64K]
>> Capabilities: [40] Power Management version 3
>> Kernel driver in use: vfio-pci
>
> What's going on here? Where does interrupt 21 come from? It should be 5!
-> this is before starting of /usr/local/bin/qemu-system-x86_64.
That's after starting of the VM:
06:07.0 Network controller: Ralink corp. RT2800 802.11n PCI
Subsystem: Linksys Device 0067
Flags: bus master, slow devsel, latency 32, IRQ 21
Memory at fd8e0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 3
Kernel driver in use: vfio-pci
Thanks,
kind regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html