Matthew was kind enough to set up a BoF for those of us interested in PCI and
MSI issues at this year's LPC. We went over several issues there: MSI, PCI
hotplug, PCIe virtualization, VGA arbitration and PCI address space
management.
MSI
---
This was probably the biggest topic; we spent almost an hour on the topic as I
recall. The main takeaways were these:
Issue:
Need to add something like James' lost interrupt code so we can better
detect platforms with buggy MSI support (along with more general
interrupt routing issues).
Owner:
Me. I'll be handling this by integrating James' patches into the PCI tree for
2.6.28.
Issue:
Storage drivers need to use the functionality provided above and print an oops
message or similar so we can pick it up and blacklist the platform.
Owner:
Matthew (I think?)
Issue:
smp_affinity and MSI are currently incompatible if MSI masking and INTX
mapping are unavailable. Need to return -EINVAL from smp_affinity changes in
this case.
Owner:
Me (happy to receive patches for this though).
Issue:
MSI API improvements. Need ways to allocate MSIs at runtime, and perhaps on a
per-CPU level and get affinity information. And of course we need a way to
get more than one legacy MSI allocated.
Owner:
Matthew is handling the first pass of this (the more than one legacy MSI
addition). I think we'll need some detailed requirements from the driver
guys to make further improvements (e.g. per-CPU or affinity stuff).
Issue:
Need better MSI platform blacklists.
Owner:
Me. I'll see if I can gather the list of issues the Fedora guys saw last time
they tried to enable MSI unconditionally. We can also improve the list
through the added debugging described above.
PCI hotplug
-----------
PCI hotplug has seen a lot of churn lately, mainly due to long overdue fixes
from Alex & Kenji-san. Now that Kristen is done with LPC related planning
and implementation, she says she'll have time to review more patches, but she
also said PCI hotplug doesn't need a dedicated maintainer. Assuming there
are no objections, I'll apply a patch to remove the associated entry from
MAINTAINERS for 2.6.28.
I'm really happy with the level of review we've been getting on hotplug
related patches these days, I hope we can keep it up. One of the main
remaining issues that I can see is adding some better detection code for our
hotplug slot drivers. It seems like we're missing something given that we
see so many systems with duplicate slot IDs; maybe we're not calling the
right ACPI methods or are calling them wrong somehow?
PCIe virtualization
-------------------
Briefly discussed the SR-IOV patches Yu has been posting recently. Except for
a couple of changes requested by Alex & Matthew, it looks like this patch set
is in pretty good shape. I'll wait for Matthew & Alex to ack the next set,
then I'll apply to my linux-next branch.
VGA arbitration
---------------
There's some code for handling legacy VGA routing floating around. Ben put it
together awhile back, and Tiago Vignatti has been looking after it lately.
It's a good interface to have for multi-seat configurations that require
multiple VGA cards to be POSTed; it mainly needs to be re-posted to the
mailing list for final review at this point (and Ben mentioned one more API
is needed to allow drivers to exclude themselves from arbitration once they
no longer need legacy VGA space).
PCI address space management
----------------------------
TJ has a bunch of code to improve address space management in Linux. We
talked for a few minutes about this at the BoF; at this point I'm just
waiting for TJ to post his stuff so we can start integrating it. Hopefully
we can start merging small pieces of it (like the multiple PCI gap stuff) for
2.6.28, and get some more eyes on the more aggressive PCI-DMAR stuff he's
been talking about soon.
Well that's all I have in the way of notes. Feel free to add your own if I
missed anything or correct me if I mischaracterized things.
Thanks,
Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
