Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 03 1月, 2018 1 次提交
  3. 27 7月, 2017 2 次提交
  5. 21 6月, 2017 1 次提交
  7. 05 6月, 2017 7 次提交
  9. 02 6月, 2017 4 次提交
  11. 31 5月, 2017 1 次提交
    • M
      qed: QL41xxx VF MSI-x table · 88072fd4
      由 Mintz, Yuval 提交于 
      The QL41xxx adapters' PCI allows a single configuration for the
MSI-x table size of all child VFs of a given PF.
The existing code wouldn't cause the management firmware to set
that value, meaning the VFs would retain the default MSI-x table
size.

Introduce a new scheme so that whenever a VF is enabled, driver
would set the number of MSI-x to be the maximum over the various
VFs' needs.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88072fd4
  13. 25 5月, 2017 1 次提交
  15. 09 5月, 2017 1 次提交
  17. 25 4月, 2017 2 次提交
  19. 04 4月, 2017 1 次提交
  21. 22 3月, 2017 8 次提交
  23. 15 3月, 2017 1 次提交
  25. 27 2月, 2017 1 次提交
    • M
      qed: Fix race with multiple VFs · fd3c615a
      由 Mintz, Yuval 提交于 
      A PF syncronizes all IOV activity relating to its VFs
by using a single workqueue handling the work.
The workqueue would reach a bitmask of pending VF events
and act upon each in turn.

Problem is that the indication of a VF message [which sets
the 'vf event' bit for that VF] arrives and is set in
the slowpath attention context, which isn't syncronized with
the processing of the events.
When multiple VFs are present, it's possible that PF would
lose the indication of one of the VF's pending evens, leading
that VF to later timeout.

Instead of adding locks/barriers, simply move from a bitmask
into a per-VF indication inside that VF entry in the PF database.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fd3c615a
  27. 21 2月, 2017 1 次提交
    • M
      qed: Reflect PF link when initializing VF · 33b2fbd0
      由 Mintz, Yuval 提交于 
      VF learns of the current link state via its bulletin board,
which might reflect either the physical link state or some
user-configured logical state.
Whenever the physical link changes or whnever such a configuration
is explicitly made by user the PF driver would update the bulletin
that the VF reads. But if neither has happened - i.e., PF still
hasn't got a physical link up and no additional configuration was
done the VF wouldn't have a valid link information available.

Simply reflect the physical link state whenever the VF is
initialized. The user could then affect it however he wants.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33b2fbd0
  29. 18 1月, 2017 1 次提交
  31. 02 1月, 2017 3 次提交
  33. 01 12月, 2016 1 次提交
    • M
      qed*: Handle-based L2-queues. · 3da7a37a
      由 Mintz, Yuval 提交于 
      The driver needs to maintain several FW/HW-indices for each one of
its queues. Currently, that mapping is done by the QED where it uses
an rx/tx array of so-called hw-cids, populating them whenever a new
queue is opened and clearing them upon destruction of said queues.

This maintenance is far from ideal - there's no real reason why
QED needs to maintain such a data-structure. It becomes even worse
when considering the fact that the PF's queues and its child VFs' queues
are all mapped into the same data-structure.
As a by-product, the set of parameters an interface needs to supply for
queue APIs is non-trivial, and some of the variables in the API
structures have different meaning depending on their exact place
in the configuration flow.

This patch re-organizes the way L2 queues are configured and maintained.
In short:
  - Required parameters for queue init are now well-defined.
  - Qed would allocate a queue-cid based on parameters.
    Upon initialization success, it would return a handle to caller.
  - Queue-handle would be maintained by entity requesting queue-init,
    not necessarily qed.
  - All further queue-APIs [update, destroy] would use the opaque
    handle as reference for the queue instead of various indices.

The possible owners of such handles:
  - PF queues [qede] - complete handles based on provided configuration.
  - VF queues [qede] - fw-context-less handles, containing only relative
    information; Only the PF-side would need the absolute indices
    for configuration, so they're omitted here.
  - VF queues [qed, PF-side] - complete handles based on VF initialization.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3da7a37a
  35. 01 11月, 2016 1 次提交
    • M
      qed: Use VF-queue feature · 5a1f965a
      由 Mintz, Yuval 提交于 
      Driver sets several restrictions about the number of supported VFs
according to available HW/FW resources.
This creates a problem as there are constellations which can't be
supported [as limitation don't accurately describe the resources],
as well as holes where enabling IOV would fail due to supposed
lack of resources.

This introduces a new interal feature - vf-queues, which would
be used to lift some of the restriction and accurately enumerate
the queues that can be used by a given PF's VFs.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a1f965a
  37. 14 10月, 2016 1 次提交
    • Y
      qed: Handle malicious VFs events · 7eff82b0
      由 Yuval Mintz 提交于 
      Malicious VFs might be caught in several different methods:
  - Misusing their bar permission and being blocked by hardware.
  - Misusing their fastpath logic and being blocked by firmware.
  - Misusing their interaction with their PF via hw-channel,
    and being blocked by PF driver.

On the first two items, firmware would indicate to driver that
the VF is to be considered malicious, but would sometime still
allow the VF to communicate with the PF [depending on the exact
nature of the malicious activity done by the VF].
The current existing logic on the PF side lacks handling of such events,
and might allow the PF to perform some incorrect configuration on behalf
of a VF that was previously indicated as malicious.

The new scheme is simple -
Once the PF determines a VF is malicious it would:
 a. Ignore any further requests on behalf of the VF-driver.
 b. Prevent any configurations initiated by the hyperuser for
    the malicious VF, as firmware isn't willing to serve such.

The malicious indication would be cleared upon the VF flr,
after which it would become usable once again.
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7eff82b0
  39. 04 10月, 2016 1 次提交