PCITodo

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.

• Subtractive decoding support

     Support subtractive decoding in PCI bridges.

• Support VGA behind a PCI bridge

     Support VGA devices behind PCI bridges.
     Good for things like multiple VGA cards.
     Requires subtractive decoding.

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