[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] MSI-X bug with ivshmem since msix_reset moved to PCI
From: |
Cam Macdonell |
Subject: |
[Qemu-devel] MSI-X bug with ivshmem since msix_reset moved to PCI |
Date: |
Thu, 23 Aug 2012 17:13:41 -0600 |
Hi Jan,
I've bisected a bug in which MSI interrupts are not being delivered to
the following patch, where msix_reset was moved in tot he PCI core.
commit cbd2d4342b3d42ab33baa99f5b7a23491b5692f2
Author: Jan Kiszka <address@hidden>
Date: Tue May 15 20:09:56 2012 -0300
msi: Invoke msi/msix_reset from PCI core
There is no point in pushing this burden to the devices, they tend to
forget to call them (like intel-hda, ahci, xhci did). Instead, reset
functions are now called from pci_device_reset. They do nothing if
MSI/MSI-X is not in use.
I've been debugging and it seems that when msix_notify() is triggered
the second test in the "if" fails
/* Send an MSI-X message */
void msix_notify(PCIDevice *dev, unsigned vector)
{
MSIMessage msg;
if (vector >= dev->msix_entries_nr || !dev->msix_entry_used[vector])
return;
…
}
here is some MSI-X debugging statements
msix_init
IVSHMEM: msix initialized (1 vectors)
IVSHMEM: using vector 0
IVSHMEM: ivshmem_reset
IVSHMEM: using vector 0
msix_reset
msix_free_irq_entries 0x7fd52d1cea20
msix_free_irq_entries() sets dev->msix_entries_nr to 0, so I think it
may be the cause.
Shouldn't ivshmem's reset (which reenables the vectors) be triggered
by the msix_reset?
Thanks,
Cam
p.s. And apologies, I should've caught this bug closer to that patch
being merged.
- [Qemu-devel] MSI-X bug with ivshmem since msix_reset moved to PCI,
Cam Macdonell <=