Revision as of 10:38, 21 August 2013 by Mst (add PCI TODO)
This page should cover all PCI related activity in KVM.
TODO: add bugzilla entry links.
=== projects in progress. contributions are still very wellcome!
- virtio device as PCI Express device
Issue: Express spec requires device can work without IO, virtio requires IO at the moment. Plan: add support for memory BARs. Developer: Michael S. Tsirkin
- Hotplug for devices behind PCI bridges
Issue: QEMU lacks support for device hotplug behind pci bridges.
Plan: - each bus gets assigned a number 0-255 - generated ACPI code writes this number to a new BSEL register, then uses existing UP/DOWN registers to probe slot status; to eject, write number to BSEL register, then slot into existing EJ This is to address the ACPI spec requirement to avoid config cycle access to any bus except PCI roots.
Note: ACPI doesn't support adding or removing bridges by hotplug. We should and prevent removal of bridges by hotplug, unless they were added by hotplug previously (and so, are not described by ACPI). Developer: Michael S. Tsirkin
- Hotplug for Q35
Issue: QEMU does not support hotplug for Q35 Plan: since we need to support hotplug of PCI devices, let's use ACPI hotplug for everything Use same interface as we do for PCI, this way same ACPI code can be reused.
Developer: Michael S. Tsirkin
- Support for different PCI express link width/speed settings
Issue: QEMU currently emulates all links at minimal width and speed. This means we don't need to emulate link negotiation, but might in theory confuse guests for assigned devices. The issue is complicated by the fact that real link speed might be limited by the slot where assigned device is put. Plan: add management interface to control the max link speed and width for the slot. Teach management to query this at slot level. For device, query it from device itself. Support link width/speed negotiation as per spec. Developer: Alex Williamson
projects that are not started yet - no owner
- PCI interrupts should be active-low
Issue: PCI INT#x interrupts are normally active-low. QEMU emulates them as active high. Works fine for windows and linux but not guaranteed for other guests. See http://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
Plan: add support for active-low interrupts in KVM. Enable this for PCI interrupts. Change DSDT appropriately.
Developer: Testing: stress-test devices with INT#x interrupts with interrupt sharing in particular
- PCI master-abort is not emulated correctly
Issue: access to disabled PCI memory normally returns all-ones (or read) and sets master abort detected bit in bridge. For express, it can also trigger AER reporting when enabled. QEMU does not emulate any of this: reads return 0, writes. Plan: add catch-all memory region with low priority in bridge, and trigger the required actions.
- Better modeling for PCI INT#x
Issue: for a device deep down a bridge hierarchy, we scan the tree upwards on each interrupt, calling map_irq at each level, this is bad for performance. Behaviour is also open-coded at each level, this is ugly. Plan: something similar to MemoryRegion API: add objects that represent PCI INT#x pings (maybe pins in general) model their connection at each level. Each time there's a change, re-map them. On data path, use pre-computed irq# to send/clear the interrupt quickly.
=== vague ideas: path to implementation not clear
- Way to figure out proper PCI connectivity options.
Issue: How do you know where you can connect a device? For PCI, this includes the legal bus addresses, hotplug support for bus, how the secondary bus is named, and whether bridges support required addressing modes. For PCI Express, there are additional options: root or downstream port, virtual bridge in root complex/upstream port. management tools end up hard-coding this information, based simply on device name, but that's ugly. Vague idea: add interfaces to figure out what can be connected to what and how, or at least the function of each device. People to contact: Laine Stump
- Fix AHCI for stability
Not related to PCI directly but modern chipsets with PCI Express support all use AHCI. Issue1: AHCI is unstable with windows guests (win7 fails to boot sometimes) Issue2: guests sometimes crash when doing ping pong migration People to contact: Alexander Graf