1. 01 1月, 2010 1 次提交
  2. 17 12月, 2009 1 次提交
  3. 05 11月, 2009 1 次提交
    • A
      PCI: acs p2p upsteram forwarding enabling · ae21ee65
      Allen Kay 提交于
      Note: dom0 checking in v4 has been separated out into 2/2.
      
      This patch enables P2P upstream forwarding in ACS capable PCIe switches.
      It solves two potential problems in virtualization environment where a PCIe
      device is assigned to a guest domain using a HW iommu such as VT-d:
      
      1) Unintentional failure caused by guest physical address programmed
         into the device's DMA that happens to match the memory address range
         of other downstream ports in the same PCIe switch.  This causes the PCI
         transaction to go to the matching downstream port instead of go to the
         root complex to get translated by VT-d as it should be.
      
      2) Malicious guest software intentionally attacks another downstream
         PCIe device by programming the DMA address into the assigned device
         that matches memory address range of the downstream PCIe port.
      
      We are in process of implementing device filtering software in KVM/XEN
      management software to allow device assignment of PCIe devices behind a PCIe
      switch only if it has ACS capability and with the P2P upstream forwarding bits
      enabled.  This patch is intended to work for both KVM and Xen environments.
      Signed-off-by: NAllen Kay <allen.m.kay@intel.com>
      Reviewed-by: NMathew Wilcox <willy@linux.intel.com>
      Reviewed-by: NChris Wright <chris@sous-sol.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      ae21ee65
  4. 10 9月, 2009 2 次提交
    • E
      PCI: Simplify hotplug mch quirk. · 0ba379ec
      Eric W. Biederman 提交于
      There is a very old quirk for the intel E7502 E7320 and E7525 memory
      controller hubs that disables usage of msi interrupts on pcie hotplug
      bridges of those devices, and disables changing the affinity of irqs.
      
      Today all we have to do to disable msi on a specific device is to set
      dev->no_msi, which is much more straightforward than the previous
      logic.
      
      The re-running of this fixup after pci hotplug happens below these
      devices is totally bogus.  All of the state we change is pure software
      state and we don't change the hardware at all.  Which means hotplug on
      the lower devices doesn't have a chance to change this state.  So we
      can safely remove the special case from the pciehp driver and the pcie
      portdriver.
      
      I suspect the special case was someone's expermental debug code that
      slipped in. Certainly it isn't mentioned in commit
      6fb8880a61510295aece04a542767161f624dffe aka BKrev:
      41966101LJ_ogfOU0m2aE6teZfQnuQ where the code first appears.
      Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      0ba379ec
    • M
      PCI: expose function reset capability in sysfs · 711d5779
      Michael S. Tsirkin 提交于
      Some devices allow an individual function to be reset without affecting
      other functions in the same device: that's what pci_reset_function does.
      For devices that have this support, expose reset attribite in sysfs.
      
      This is useful e.g. for virtualization, where a qemu userspace
      process wants to reset the device when the guest is reset,
      to emulate machine reboot as closely as possible.
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      711d5779
  5. 30 8月, 2009 1 次提交
    • C
      PCI SR-IOV: correct broken resource alignment calculations · 6faf17f6
      Chris Wright 提交于
      An SR-IOV capable device includes an SR-IOV PCIe capability which
      describes the Virtual Function (VF) BAR requirements.  A typical SR-IOV
      device can support multiple VFs whose BARs must be in a contiguous region,
      effectively an array of VF BARs.  The BAR reports the size requirement
      for a single VF.  We calculate the full range needed by simply multiplying
      the VF BAR size with the number of possible VFs and create a resource
      spanning the full range.
      
      This all seems sane enough except it artificially inflates the alignment
      requirement for the VF BAR.  The VF BAR need only be aligned to the size
      of a single BAR not the contiguous range of VF BARs.  This can cause us
      to fail to allocate resources for the BAR despite the fact that we
      actually have enough space.
      
      This patch adds a thin PCI specific layer over the generic
      resource_alignment() function which is aware of the special nature of
      VF BARs and does sorting and allocation based on the smaller alignment
      requirement.
      
      I recognize that while resource_alignment is generic, it's basically a
      PCI helper.  An alternative to this patch is to add PCI VF BAR specific
      information to struct resource.  I opted for the extra layer rather than
      adding such PCI specific information to struct resource.  This does
      have the slight downside that we don't cache the BAR size and re-read
      for each alignment query (happens a small handful of times during boot
      for each VF BAR).
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Yu Zhao <yu.zhao@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6faf17f6
  6. 18 5月, 2009 2 次提交
  7. 31 3月, 2009 1 次提交
  8. 21 3月, 2009 8 次提交
  9. 14 2月, 2009 1 次提交
  10. 17 1月, 2009 1 次提交
    • R
      PCI PM: Restore standard config registers of all devices early · aa8c6c93
      Rafael J. Wysocki 提交于
      There is a problem in our handling of suspend-resume of PCI devices that
      many of them have their standard config registers restored with
      interrupts enabled and they are put into the full power state with
      interrupts enabled as well.  This may lead to the following scenario:
        * an interrupt vector is shared between two or more devices
        * one device is resumed earlier and generates an interrupt
        * the interrupt handler of another device tries to handle it and
          attempts to access the device the config space of which hasn't been
          restored yet and/or which still is in a low power state
        * the system crashes as a result
      
      To prevent this from happening we should restore the standard
      configuration registers of all devices with interrupts disabled and we
      should put them into the D0 power state right after that.
      Unfortunately, this cannot be done using the existing
      pci_set_power_state(), because it can sleep.  Also, to do it we have to
      make sure that the config spaces of all devices were actually saved
      during suspend.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      aa8c6c93
  11. 08 1月, 2009 11 次提交
  12. 23 10月, 2008 1 次提交
  13. 21 10月, 2008 4 次提交
  14. 17 7月, 2008 1 次提交
  15. 08 7月, 2008 2 次提交
    • R
      PCI ACPI: Rework PCI handling of wake-up · eb9d0fe4
      Rafael J. Wysocki 提交于
      * Introduce function acpi_pm_device_sleep_wake() for enabling and
        disabling the system wake-up capability of devices that are power
        manageable by ACPI.
      
      * Introduce function acpi_bus_can_wakeup() allowing other (dependent)
        subsystems to check if ACPI is able to enable the system wake-up
        capability of given device.
      
      * Introduce callback .sleep_wake() in struct pci_platform_pm_ops and
        for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake().
      
      * Introduce callback .can_wakeup() in struct pci_platform_pm_ops and
        for the ACPI 'driver' make it use acpi_bus_can_wakeup().
      
      * Move the PME# handlig code out of pci_enable_wake() and split it
        into two functions, pci_pme_capable() and pci_pme_active(),
        allowing the caller to check if given device is capable of
        generating PME# from given power state and to enable/disable the
        device's PME# functionality, respectively.
      
      * Modify pci_enable_wake() to use the new ACPI callbacks and the new
        PME#-related functions.
      
      * Drop the generic .platform_enable_wakeup() callback that is not
        used any more.
      
      * Introduce device_set_wakeup_capable() that will set the
        power.can_wakeup flag of given device.
      
      * Rework PCI device PM initialization so that, if given device is
        capable of generating wake-up events, either natively through the
        PME# mechanism, or with the help of the platform, its
        power.can_wakeup flag is set and its power.should_wakeup flag is
        unset as appropriate.
      
      * Make ACPI set the power.can_wakeup flag for devices found to be
        wake-up capable by it.
      
      * Make the ACPI wake-up code enable/disable GPEs for devices that
        have the wakeup.flags.prepared flag set (which means that their
        wake-up power has been enabled).
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      eb9d0fe4
    • R
      PCI: Introduce platform_pci_power_manageable function · 961d9120
      Rafael J. Wysocki 提交于
      Introduce function pointer platform_pci_power_manageable to be used
      by the platform-related code to point to a function allowing us to
      check if given device is power manageable by the platform.
      
      Introduce acpi_pci_power_manageable() playing that role for ACPI.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      961d9120
  16. 03 7月, 2008 1 次提交
    • B
      PCI: Limit VPD read/write lengths for Broadcom 5706, 5708, 5709 rev. · 99cb233d
      Benjamin Li 提交于
      For Broadcom 5706, 5708, 5709 rev. A nics, any read beyond the
      VPD end tag will hang the device.  This problem was initially
      observed when a vpd entry was created in sysfs
      ('/sys/bus/pci/devices/<id>/vpd').   A read to this sysfs entry
      will dump 32k of data.  Reading a full 32k will cause an access
      beyond the VPD end tag causing the device to hang.  Once the device
      is hung, the bnx2 driver will not be able to reset the device.
      We believe that it is legal to read beyond the end tag and
      therefore the solution is to limit the read/write length.
      
      A majority of this patch is from Matthew Wilcox who gave code for
      reworking the PCI vpd size information.  A PCI quirk added for the
      Broadcom NIC's to limit the read/write's.
      Signed-off-by: NBenjamin Li <benli@broadcom.com>
      Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      99cb233d
  17. 12 6月, 2008 1 次提交