2007-05-09 09:00:38 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2004, 2005 Topspin Communications. All rights reserved.
|
2008-07-26 01:32:52 +08:00
|
|
|
* Copyright (c) 2005, 2006, 2007, 2008 Mellanox Technologies. All rights reserved.
|
2007-05-09 09:00:38 +08:00
|
|
|
* Copyright (c) 2005, 2006, 2007 Cisco Systems, Inc. All rights reserved.
|
|
|
|
*
|
|
|
|
* This software is available to you under a choice of one of two
|
|
|
|
* licenses. You may choose to be licensed under the terms of the GNU
|
|
|
|
* General Public License (GPL) Version 2, available from the file
|
|
|
|
* COPYING in the main directory of this source tree, or the
|
|
|
|
* OpenIB.org BSD license below:
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or
|
|
|
|
* without modification, are permitted provided that the following
|
|
|
|
* conditions are met:
|
|
|
|
*
|
|
|
|
* - Redistributions of source code must retain the above
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
* disclaimer.
|
|
|
|
*
|
|
|
|
* - Redistributions in binary form must reproduce the above
|
|
|
|
* copyright notice, this list of conditions and the following
|
|
|
|
* disclaimer in the documentation and/or other materials
|
|
|
|
* provided with the distribution.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
|
|
|
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
|
|
|
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
|
|
|
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
|
|
|
|
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
|
|
|
|
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
|
|
|
|
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
|
|
* SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/sched.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2011-05-28 04:14:23 +08:00
|
|
|
#include <linux/export.h>
|
2007-05-09 09:00:38 +08:00
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
|
|
|
|
#include <linux/mlx4/cmd.h>
|
2013-06-13 18:19:11 +08:00
|
|
|
#include <linux/mlx4/device.h>
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
#include <linux/semaphore.h>
|
2012-08-03 16:40:45 +08:00
|
|
|
#include <rdma/ib_smi.h>
|
2015-01-25 22:59:42 +08:00
|
|
|
#include <linux/delay.h>
|
2007-05-09 09:00:38 +08:00
|
|
|
|
|
|
|
#include <asm/io.h>
|
|
|
|
|
|
|
|
#include "mlx4.h"
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
#include "fw.h"
|
2007-05-09 09:00:38 +08:00
|
|
|
|
|
|
|
#define CMD_POLL_TOKEN 0xffff
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
#define INBOX_MASK 0xffffffffffffff00ULL
|
|
|
|
|
|
|
|
#define CMD_CHAN_VER 1
|
|
|
|
#define CMD_CHAN_IF_REV 1
|
2007-05-09 09:00:38 +08:00
|
|
|
|
|
|
|
enum {
|
|
|
|
/* command completed successfully: */
|
|
|
|
CMD_STAT_OK = 0x00,
|
|
|
|
/* Internal error (such as a bus error) occurred while processing command: */
|
|
|
|
CMD_STAT_INTERNAL_ERR = 0x01,
|
|
|
|
/* Operation/command not supported or opcode modifier not supported: */
|
|
|
|
CMD_STAT_BAD_OP = 0x02,
|
|
|
|
/* Parameter not supported or parameter out of range: */
|
|
|
|
CMD_STAT_BAD_PARAM = 0x03,
|
|
|
|
/* System not enabled or bad system state: */
|
|
|
|
CMD_STAT_BAD_SYS_STATE = 0x04,
|
|
|
|
/* Attempt to access reserved or unallocaterd resource: */
|
|
|
|
CMD_STAT_BAD_RESOURCE = 0x05,
|
|
|
|
/* Requested resource is currently executing a command, or is otherwise busy: */
|
|
|
|
CMD_STAT_RESOURCE_BUSY = 0x06,
|
|
|
|
/* Required capability exceeds device limits: */
|
|
|
|
CMD_STAT_EXCEED_LIM = 0x08,
|
|
|
|
/* Resource is not in the appropriate state or ownership: */
|
|
|
|
CMD_STAT_BAD_RES_STATE = 0x09,
|
|
|
|
/* Index out of range: */
|
|
|
|
CMD_STAT_BAD_INDEX = 0x0a,
|
|
|
|
/* FW image corrupted: */
|
|
|
|
CMD_STAT_BAD_NVMEM = 0x0b,
|
2008-07-23 05:19:39 +08:00
|
|
|
/* Error in ICM mapping (e.g. not enough auxiliary ICM pages to execute command): */
|
|
|
|
CMD_STAT_ICM_ERROR = 0x0c,
|
2007-05-09 09:00:38 +08:00
|
|
|
/* Attempt to modify a QP/EE which is not in the presumed state: */
|
|
|
|
CMD_STAT_BAD_QP_STATE = 0x10,
|
|
|
|
/* Bad segment parameters (Address/Size): */
|
|
|
|
CMD_STAT_BAD_SEG_PARAM = 0x20,
|
|
|
|
/* Memory Region has Memory Windows bound to: */
|
|
|
|
CMD_STAT_REG_BOUND = 0x21,
|
|
|
|
/* HCA local attached memory not present: */
|
|
|
|
CMD_STAT_LAM_NOT_PRE = 0x22,
|
|
|
|
/* Bad management packet (silently discarded): */
|
|
|
|
CMD_STAT_BAD_PKT = 0x30,
|
|
|
|
/* More outstanding CQEs in CQ than new CQ size: */
|
2009-07-07 07:10:03 +08:00
|
|
|
CMD_STAT_BAD_SIZE = 0x40,
|
|
|
|
/* Multi Function device support required: */
|
|
|
|
CMD_STAT_MULTI_FUNC_REQ = 0x50,
|
2007-05-09 09:00:38 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
HCR_IN_PARAM_OFFSET = 0x00,
|
|
|
|
HCR_IN_MODIFIER_OFFSET = 0x08,
|
|
|
|
HCR_OUT_PARAM_OFFSET = 0x0c,
|
|
|
|
HCR_TOKEN_OFFSET = 0x14,
|
|
|
|
HCR_STATUS_OFFSET = 0x18,
|
|
|
|
|
|
|
|
HCR_OPMOD_SHIFT = 12,
|
|
|
|
HCR_T_BIT = 21,
|
|
|
|
HCR_E_BIT = 22,
|
|
|
|
HCR_GO_BIT = 23
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
2007-08-07 16:18:52 +08:00
|
|
|
GO_BIT_TIMEOUT_MSECS = 10000
|
2007-05-09 09:00:38 +08:00
|
|
|
};
|
|
|
|
|
2013-06-28 00:05:21 +08:00
|
|
|
enum mlx4_vlan_transition {
|
|
|
|
MLX4_VLAN_TRANSITION_VST_VST = 0,
|
|
|
|
MLX4_VLAN_TRANSITION_VST_VGT = 1,
|
|
|
|
MLX4_VLAN_TRANSITION_VGT_VST = 2,
|
|
|
|
MLX4_VLAN_TRANSITION_VGT_VGT = 3,
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
struct mlx4_cmd_context {
|
|
|
|
struct completion done;
|
|
|
|
int result;
|
|
|
|
int next;
|
|
|
|
u64 out_param;
|
|
|
|
u16 token;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
u8 fw_status;
|
2007-05-09 09:00:38 +08:00
|
|
|
};
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
static int mlx4_master_process_vhcr(struct mlx4_dev *dev, int slave,
|
|
|
|
struct mlx4_vhcr_cmd *in_vhcr);
|
|
|
|
|
2008-04-17 12:01:04 +08:00
|
|
|
static int mlx4_status_to_errno(u8 status)
|
|
|
|
{
|
2007-05-09 09:00:38 +08:00
|
|
|
static const int trans_table[] = {
|
|
|
|
[CMD_STAT_INTERNAL_ERR] = -EIO,
|
|
|
|
[CMD_STAT_BAD_OP] = -EPERM,
|
|
|
|
[CMD_STAT_BAD_PARAM] = -EINVAL,
|
|
|
|
[CMD_STAT_BAD_SYS_STATE] = -ENXIO,
|
|
|
|
[CMD_STAT_BAD_RESOURCE] = -EBADF,
|
|
|
|
[CMD_STAT_RESOURCE_BUSY] = -EBUSY,
|
|
|
|
[CMD_STAT_EXCEED_LIM] = -ENOMEM,
|
|
|
|
[CMD_STAT_BAD_RES_STATE] = -EBADF,
|
|
|
|
[CMD_STAT_BAD_INDEX] = -EBADF,
|
|
|
|
[CMD_STAT_BAD_NVMEM] = -EFAULT,
|
2008-07-23 05:19:39 +08:00
|
|
|
[CMD_STAT_ICM_ERROR] = -ENFILE,
|
2007-05-09 09:00:38 +08:00
|
|
|
[CMD_STAT_BAD_QP_STATE] = -EINVAL,
|
|
|
|
[CMD_STAT_BAD_SEG_PARAM] = -EFAULT,
|
|
|
|
[CMD_STAT_REG_BOUND] = -EBUSY,
|
|
|
|
[CMD_STAT_LAM_NOT_PRE] = -EAGAIN,
|
|
|
|
[CMD_STAT_BAD_PKT] = -EINVAL,
|
|
|
|
[CMD_STAT_BAD_SIZE] = -ENOMEM,
|
2009-07-07 07:10:03 +08:00
|
|
|
[CMD_STAT_MULTI_FUNC_REQ] = -EACCES,
|
2007-05-09 09:00:38 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
if (status >= ARRAY_SIZE(trans_table) ||
|
|
|
|
(status != CMD_STAT_OK && trans_table[status] == 0))
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
return trans_table[status];
|
|
|
|
}
|
|
|
|
|
2011-12-19 12:03:53 +08:00
|
|
|
static u8 mlx4_errno_to_status(int errno)
|
|
|
|
{
|
|
|
|
switch (errno) {
|
|
|
|
case -EPERM:
|
|
|
|
return CMD_STAT_BAD_OP;
|
|
|
|
case -EINVAL:
|
|
|
|
return CMD_STAT_BAD_PARAM;
|
|
|
|
case -ENXIO:
|
|
|
|
return CMD_STAT_BAD_SYS_STATE;
|
|
|
|
case -EBUSY:
|
|
|
|
return CMD_STAT_RESOURCE_BUSY;
|
|
|
|
case -ENOMEM:
|
|
|
|
return CMD_STAT_EXCEED_LIM;
|
|
|
|
case -ENFILE:
|
|
|
|
return CMD_STAT_ICM_ERROR;
|
|
|
|
default:
|
|
|
|
return CMD_STAT_INTERNAL_ERR;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-25 22:59:39 +08:00
|
|
|
static int mlx4_internal_err_ret_value(struct mlx4_dev *dev, u16 op,
|
|
|
|
u8 op_modifier)
|
|
|
|
{
|
|
|
|
switch (op) {
|
|
|
|
case MLX4_CMD_UNMAP_ICM:
|
|
|
|
case MLX4_CMD_UNMAP_ICM_AUX:
|
|
|
|
case MLX4_CMD_UNMAP_FA:
|
|
|
|
case MLX4_CMD_2RST_QP:
|
|
|
|
case MLX4_CMD_HW2SW_EQ:
|
|
|
|
case MLX4_CMD_HW2SW_CQ:
|
|
|
|
case MLX4_CMD_HW2SW_SRQ:
|
|
|
|
case MLX4_CMD_HW2SW_MPT:
|
|
|
|
case MLX4_CMD_CLOSE_HCA:
|
|
|
|
case MLX4_QP_FLOW_STEERING_DETACH:
|
|
|
|
case MLX4_CMD_FREE_RES:
|
|
|
|
case MLX4_CMD_CLOSE_PORT:
|
|
|
|
return CMD_STAT_OK;
|
|
|
|
|
|
|
|
case MLX4_CMD_QP_ATTACH:
|
|
|
|
/* On Detach case return success */
|
|
|
|
if (op_modifier == 0)
|
|
|
|
return CMD_STAT_OK;
|
|
|
|
return mlx4_status_to_errno(CMD_STAT_INTERNAL_ERR);
|
|
|
|
|
|
|
|
default:
|
|
|
|
return mlx4_status_to_errno(CMD_STAT_INTERNAL_ERR);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mlx4_closing_cmd_fatal_error(u16 op, u8 fw_status)
|
|
|
|
{
|
|
|
|
/* Any error during the closing commands below is considered fatal */
|
|
|
|
if (op == MLX4_CMD_CLOSE_HCA ||
|
|
|
|
op == MLX4_CMD_HW2SW_EQ ||
|
|
|
|
op == MLX4_CMD_HW2SW_CQ ||
|
|
|
|
op == MLX4_CMD_2RST_QP ||
|
|
|
|
op == MLX4_CMD_HW2SW_SRQ ||
|
|
|
|
op == MLX4_CMD_SYNC_TPT ||
|
|
|
|
op == MLX4_CMD_UNMAP_ICM ||
|
|
|
|
op == MLX4_CMD_UNMAP_ICM_AUX ||
|
|
|
|
op == MLX4_CMD_UNMAP_FA)
|
|
|
|
return 1;
|
|
|
|
/* Error on MLX4_CMD_HW2SW_MPT is fatal except when fw status equals
|
|
|
|
* CMD_STAT_REG_BOUND.
|
|
|
|
* This status indicates that memory region has memory windows bound to it
|
|
|
|
* which may result from invalid user space usage and is not fatal.
|
|
|
|
*/
|
|
|
|
if (op == MLX4_CMD_HW2SW_MPT && fw_status != CMD_STAT_REG_BOUND)
|
|
|
|
return 1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mlx4_cmd_reset_flow(struct mlx4_dev *dev, u16 op, u8 op_modifier,
|
|
|
|
int err)
|
|
|
|
{
|
|
|
|
/* Only if reset flow is really active return code is based on
|
|
|
|
* command, otherwise current error code is returned.
|
|
|
|
*/
|
|
|
|
if (mlx4_internal_err_reset) {
|
|
|
|
mlx4_enter_error_state(dev->persist);
|
|
|
|
err = mlx4_internal_err_ret_value(dev, op, op_modifier);
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
static int comm_pending(struct mlx4_dev *dev)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
u32 status = readl(&priv->mfunc.comm->slave_read);
|
|
|
|
|
|
|
|
return (swab32(status) >> 31) != priv->cmd.comm_toggle;
|
|
|
|
}
|
|
|
|
|
2015-01-25 22:59:43 +08:00
|
|
|
static int mlx4_comm_cmd_post(struct mlx4_dev *dev, u8 cmd, u16 param)
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
u32 val;
|
|
|
|
|
2015-01-25 22:59:43 +08:00
|
|
|
/* To avoid writing to unknown addresses after the device state was
|
|
|
|
* changed to internal error and the function was rest,
|
|
|
|
* check the INTERNAL_ERROR flag which is updated under
|
|
|
|
* device_state_mutex lock.
|
|
|
|
*/
|
|
|
|
mutex_lock(&dev->persist->device_state_mutex);
|
|
|
|
|
|
|
|
if (dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR) {
|
|
|
|
mutex_unlock(&dev->persist->device_state_mutex);
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
priv->cmd.comm_toggle ^= 1;
|
|
|
|
val = param | (cmd << 16) | (priv->cmd.comm_toggle << 31);
|
|
|
|
__raw_writel((__force u32) cpu_to_be32(val),
|
|
|
|
&priv->mfunc.comm->slave_write);
|
|
|
|
mmiowb();
|
2015-01-25 22:59:43 +08:00
|
|
|
mutex_unlock(&dev->persist->device_state_mutex);
|
|
|
|
return 0;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mlx4_comm_cmd_poll(struct mlx4_dev *dev, u8 cmd, u16 param,
|
|
|
|
unsigned long timeout)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
unsigned long end;
|
|
|
|
int err = 0;
|
|
|
|
int ret_from_pending = 0;
|
|
|
|
|
|
|
|
/* First, verify that the master reports correct status */
|
|
|
|
if (comm_pending(dev)) {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_warn(dev, "Communication channel is not idle - my toggle is %d (cmd:0x%x)\n",
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
priv->cmd.comm_toggle, cmd);
|
|
|
|
return -EAGAIN;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Write command */
|
|
|
|
down(&priv->cmd.poll_sem);
|
2015-01-25 22:59:43 +08:00
|
|
|
if (mlx4_comm_cmd_post(dev, cmd, param)) {
|
|
|
|
/* Only in case the device state is INTERNAL_ERROR,
|
|
|
|
* mlx4_comm_cmd_post returns with an error
|
|
|
|
*/
|
|
|
|
err = mlx4_status_to_errno(CMD_STAT_INTERNAL_ERR);
|
|
|
|
goto out;
|
|
|
|
}
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
|
|
|
|
end = msecs_to_jiffies(timeout) + jiffies;
|
|
|
|
while (comm_pending(dev) && time_before(jiffies, end))
|
|
|
|
cond_resched();
|
|
|
|
ret_from_pending = comm_pending(dev);
|
|
|
|
if (ret_from_pending) {
|
|
|
|
/* check if the slave is trying to boot in the middle of
|
|
|
|
* FLR process. The only non-zero result in the RESET command
|
|
|
|
* is MLX4_DELAY_RESET_SLAVE*/
|
|
|
|
if ((MLX4_COMM_CMD_RESET == cmd)) {
|
|
|
|
err = MLX4_DELAY_RESET_SLAVE;
|
2015-01-25 22:59:43 +08:00
|
|
|
goto out;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
} else {
|
2015-01-25 22:59:43 +08:00
|
|
|
mlx4_warn(dev, "Communication channel command 0x%x timed out\n",
|
|
|
|
cmd);
|
|
|
|
err = mlx4_status_to_errno(CMD_STAT_INTERNAL_ERR);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-25 22:59:43 +08:00
|
|
|
if (err)
|
|
|
|
mlx4_enter_error_state(dev->persist);
|
|
|
|
out:
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
up(&priv->cmd.poll_sem);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2015-01-25 22:59:43 +08:00
|
|
|
static int mlx4_comm_cmd_wait(struct mlx4_dev *dev, u8 vhcr_cmd,
|
|
|
|
u16 param, u16 op, unsigned long timeout)
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
{
|
|
|
|
struct mlx4_cmd *cmd = &mlx4_priv(dev)->cmd;
|
|
|
|
struct mlx4_cmd_context *context;
|
2012-03-18 12:32:08 +08:00
|
|
|
unsigned long end;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
down(&cmd->event_sem);
|
|
|
|
|
|
|
|
spin_lock(&cmd->context_lock);
|
|
|
|
BUG_ON(cmd->free_head < 0);
|
|
|
|
context = &cmd->context[cmd->free_head];
|
|
|
|
context->token += cmd->token_mask + 1;
|
|
|
|
cmd->free_head = context->next;
|
|
|
|
spin_unlock(&cmd->context_lock);
|
|
|
|
|
2015-01-25 22:59:39 +08:00
|
|
|
reinit_completion(&context->done);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
|
2015-01-25 22:59:43 +08:00
|
|
|
if (mlx4_comm_cmd_post(dev, vhcr_cmd, param)) {
|
|
|
|
/* Only in case the device state is INTERNAL_ERROR,
|
|
|
|
* mlx4_comm_cmd_post returns with an error
|
|
|
|
*/
|
|
|
|
err = mlx4_status_to_errno(CMD_STAT_INTERNAL_ERR);
|
|
|
|
goto out;
|
|
|
|
}
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
|
|
|
|
if (!wait_for_completion_timeout(&context->done,
|
|
|
|
msecs_to_jiffies(timeout))) {
|
2015-01-25 22:59:43 +08:00
|
|
|
mlx4_warn(dev, "communication channel command 0x%x (op=0x%x) timed out\n",
|
|
|
|
vhcr_cmd, op);
|
|
|
|
goto out_reset;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
err = context->result;
|
|
|
|
if (err && context->fw_status != CMD_STAT_MULTI_FUNC_REQ) {
|
|
|
|
mlx4_err(dev, "command 0x%x failed: fw status = 0x%x\n",
|
2015-01-25 22:59:43 +08:00
|
|
|
vhcr_cmd, context->fw_status);
|
|
|
|
if (mlx4_closing_cmd_fatal_error(op, context->fw_status))
|
|
|
|
goto out_reset;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
|
|
|
|
2012-03-18 12:32:08 +08:00
|
|
|
/* wait for comm channel ready
|
|
|
|
* this is necessary for prevention the race
|
|
|
|
* when switching between event to polling mode
|
2015-01-25 22:59:43 +08:00
|
|
|
* Skipping this section in case the device is in FATAL_ERROR state,
|
|
|
|
* In this state, no commands are sent via the comm channel until
|
|
|
|
* the device has returned from reset.
|
2012-03-18 12:32:08 +08:00
|
|
|
*/
|
2015-01-25 22:59:43 +08:00
|
|
|
if (!(dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR)) {
|
|
|
|
end = msecs_to_jiffies(timeout) + jiffies;
|
|
|
|
while (comm_pending(dev) && time_before(jiffies, end))
|
|
|
|
cond_resched();
|
|
|
|
}
|
|
|
|
goto out;
|
2012-03-18 12:32:08 +08:00
|
|
|
|
2015-01-25 22:59:43 +08:00
|
|
|
out_reset:
|
|
|
|
err = mlx4_status_to_errno(CMD_STAT_INTERNAL_ERR);
|
|
|
|
mlx4_enter_error_state(dev->persist);
|
|
|
|
out:
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
spin_lock(&cmd->context_lock);
|
|
|
|
context->next = cmd->free_head;
|
|
|
|
cmd->free_head = context - cmd->context;
|
|
|
|
spin_unlock(&cmd->context_lock);
|
|
|
|
|
|
|
|
up(&cmd->event_sem);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
int mlx4_comm_cmd(struct mlx4_dev *dev, u8 cmd, u16 param,
|
2015-01-25 22:59:43 +08:00
|
|
|
u16 op, unsigned long timeout)
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
{
|
2015-01-25 22:59:43 +08:00
|
|
|
if (dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR)
|
|
|
|
return mlx4_status_to_errno(CMD_STAT_INTERNAL_ERR);
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (mlx4_priv(dev)->cmd.use_events)
|
2015-01-25 22:59:43 +08:00
|
|
|
return mlx4_comm_cmd_wait(dev, cmd, param, op, timeout);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
return mlx4_comm_cmd_poll(dev, cmd, param, timeout);
|
|
|
|
}
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
static int cmd_pending(struct mlx4_dev *dev)
|
|
|
|
{
|
2012-07-20 17:55:43 +08:00
|
|
|
u32 status;
|
|
|
|
|
2015-01-25 22:59:35 +08:00
|
|
|
if (pci_channel_offline(dev->persist->pdev))
|
2012-07-20 17:55:43 +08:00
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
status = readl(mlx4_priv(dev)->cmd.hcr + HCR_STATUS_OFFSET);
|
2007-05-09 09:00:38 +08:00
|
|
|
|
|
|
|
return (status & swab32(1 << HCR_GO_BIT)) ||
|
|
|
|
(mlx4_priv(dev)->cmd.toggle ==
|
|
|
|
!!(status & swab32(1 << HCR_T_BIT)));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mlx4_cmd_post(struct mlx4_dev *dev, u64 in_param, u64 out_param,
|
|
|
|
u32 in_modifier, u8 op_modifier, u16 op, u16 token,
|
|
|
|
int event)
|
|
|
|
{
|
|
|
|
struct mlx4_cmd *cmd = &mlx4_priv(dev)->cmd;
|
|
|
|
u32 __iomem *hcr = cmd->hcr;
|
2015-01-25 22:59:39 +08:00
|
|
|
int ret = -EIO;
|
2007-05-09 09:00:38 +08:00
|
|
|
unsigned long end;
|
|
|
|
|
2015-01-25 22:59:39 +08:00
|
|
|
mutex_lock(&dev->persist->device_state_mutex);
|
|
|
|
/* To avoid writing to unknown addresses after the device state was
|
|
|
|
* changed to internal error and the chip was reset,
|
|
|
|
* check the INTERNAL_ERROR flag which is updated under
|
|
|
|
* device_state_mutex lock.
|
|
|
|
*/
|
|
|
|
if (pci_channel_offline(dev->persist->pdev) ||
|
|
|
|
(dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR)) {
|
2012-07-20 17:55:43 +08:00
|
|
|
/*
|
|
|
|
* Device is going through error recovery
|
|
|
|
* and cannot accept commands.
|
|
|
|
*/
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
end = jiffies;
|
|
|
|
if (event)
|
2007-08-07 16:18:52 +08:00
|
|
|
end += msecs_to_jiffies(GO_BIT_TIMEOUT_MSECS);
|
2007-05-09 09:00:38 +08:00
|
|
|
|
|
|
|
while (cmd_pending(dev)) {
|
2015-01-25 22:59:35 +08:00
|
|
|
if (pci_channel_offline(dev->persist->pdev)) {
|
2012-07-20 17:55:43 +08:00
|
|
|
/*
|
|
|
|
* Device is going through error recovery
|
|
|
|
* and cannot accept commands.
|
|
|
|
*/
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (time_after_eq(jiffies, end)) {
|
|
|
|
mlx4_err(dev, "%s:cmd_pending failed\n", __func__);
|
2007-05-09 09:00:38 +08:00
|
|
|
goto out;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
2007-05-09 09:00:38 +08:00
|
|
|
cond_resched();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We use writel (instead of something like memcpy_toio)
|
|
|
|
* because writes of less than 32 bits to the HCR don't work
|
|
|
|
* (and some architectures such as ia64 implement memcpy_toio
|
|
|
|
* in terms of writeb).
|
|
|
|
*/
|
|
|
|
__raw_writel((__force u32) cpu_to_be32(in_param >> 32), hcr + 0);
|
|
|
|
__raw_writel((__force u32) cpu_to_be32(in_param & 0xfffffffful), hcr + 1);
|
|
|
|
__raw_writel((__force u32) cpu_to_be32(in_modifier), hcr + 2);
|
|
|
|
__raw_writel((__force u32) cpu_to_be32(out_param >> 32), hcr + 3);
|
|
|
|
__raw_writel((__force u32) cpu_to_be32(out_param & 0xfffffffful), hcr + 4);
|
|
|
|
__raw_writel((__force u32) cpu_to_be32(token << 16), hcr + 5);
|
|
|
|
|
|
|
|
/* __raw_writel may not order writes. */
|
|
|
|
wmb();
|
|
|
|
|
|
|
|
__raw_writel((__force u32) cpu_to_be32((1 << HCR_GO_BIT) |
|
|
|
|
(cmd->toggle << HCR_T_BIT) |
|
|
|
|
(event ? (1 << HCR_E_BIT) : 0) |
|
|
|
|
(op_modifier << HCR_OPMOD_SHIFT) |
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
op), hcr + 6);
|
2007-10-10 10:59:18 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure that our HCR writes don't get mixed in with
|
|
|
|
* writes from another CPU starting a FW command.
|
|
|
|
*/
|
|
|
|
mmiowb();
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
cmd->toggle = cmd->toggle ^ 1;
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
|
|
|
|
out:
|
2015-01-25 22:59:39 +08:00
|
|
|
if (ret)
|
|
|
|
mlx4_warn(dev, "Could not post command 0x%x: ret=%d, in_param=0x%llx, in_mod=0x%x, op_mod=0x%x\n",
|
|
|
|
op, ret, in_param, in_modifier, op_modifier);
|
|
|
|
mutex_unlock(&dev->persist->device_state_mutex);
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
static int mlx4_slave_cmd(struct mlx4_dev *dev, u64 in_param, u64 *out_param,
|
|
|
|
int out_is_imm, u32 in_modifier, u8 op_modifier,
|
|
|
|
u16 op, unsigned long timeout)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct mlx4_vhcr_cmd *vhcr = priv->mfunc.vhcr;
|
|
|
|
int ret;
|
|
|
|
|
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
before mlx4_multi_func_init(). However, for unlucky configurations,
mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
calls into mlx4_slave_cmd(), and that immediately tries to do
down(&priv->cmd.slave_sem);
but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
(which we haven't called yet). The next thing it tries to do is access
priv->mfunc.vhcr, but that hasn't been allocated yet.
Fix this by moving the initialization of slave_sem and vhcr up into
mlx4_cmd_init(). Also, since slave_sem is really just being used as a
mutex, convert it into a slave_cmd_mutex.
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-09-26 12:24:07 +08:00
|
|
|
mutex_lock(&priv->cmd.slave_cmd_mutex);
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
vhcr->in_param = cpu_to_be64(in_param);
|
|
|
|
vhcr->out_param = out_param ? cpu_to_be64(*out_param) : 0;
|
|
|
|
vhcr->in_modifier = cpu_to_be32(in_modifier);
|
|
|
|
vhcr->opcode = cpu_to_be16((((u16) op_modifier) << 12) | (op & 0xfff));
|
|
|
|
vhcr->token = cpu_to_be16(CMD_POLL_TOKEN);
|
|
|
|
vhcr->status = 0;
|
|
|
|
vhcr->flags = !!(priv->cmd.use_events) << 6;
|
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
before mlx4_multi_func_init(). However, for unlucky configurations,
mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
calls into mlx4_slave_cmd(), and that immediately tries to do
down(&priv->cmd.slave_sem);
but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
(which we haven't called yet). The next thing it tries to do is access
priv->mfunc.vhcr, but that hasn't been allocated yet.
Fix this by moving the initialization of slave_sem and vhcr up into
mlx4_cmd_init(). Also, since slave_sem is really just being used as a
mutex, convert it into a slave_cmd_mutex.
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-09-26 12:24:07 +08:00
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (mlx4_is_master(dev)) {
|
|
|
|
ret = mlx4_master_process_vhcr(dev, dev->caps.function, vhcr);
|
|
|
|
if (!ret) {
|
|
|
|
if (out_is_imm) {
|
|
|
|
if (out_param)
|
|
|
|
*out_param =
|
|
|
|
be64_to_cpu(vhcr->out_param);
|
|
|
|
else {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_err(dev, "response expected while output mailbox is NULL for command 0x%x\n",
|
|
|
|
op);
|
2011-12-19 12:03:53 +08:00
|
|
|
vhcr->status = CMD_STAT_BAD_PARAM;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
|
|
|
}
|
2011-12-19 12:03:53 +08:00
|
|
|
ret = mlx4_status_to_errno(vhcr->status);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
2015-01-25 22:59:43 +08:00
|
|
|
if (ret &&
|
|
|
|
dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR)
|
|
|
|
ret = mlx4_internal_err_ret_value(dev, op, op_modifier);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
} else {
|
2015-01-25 22:59:43 +08:00
|
|
|
ret = mlx4_comm_cmd(dev, MLX4_COMM_CMD_VHCR_POST, 0, op,
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
MLX4_COMM_TIME + timeout);
|
|
|
|
if (!ret) {
|
|
|
|
if (out_is_imm) {
|
|
|
|
if (out_param)
|
|
|
|
*out_param =
|
|
|
|
be64_to_cpu(vhcr->out_param);
|
|
|
|
else {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_err(dev, "response expected while output mailbox is NULL for command 0x%x\n",
|
|
|
|
op);
|
2011-12-19 12:03:53 +08:00
|
|
|
vhcr->status = CMD_STAT_BAD_PARAM;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
|
|
|
}
|
2011-12-19 12:03:53 +08:00
|
|
|
ret = mlx4_status_to_errno(vhcr->status);
|
2015-01-25 22:59:43 +08:00
|
|
|
} else {
|
|
|
|
if (dev->persist->state &
|
|
|
|
MLX4_DEVICE_STATE_INTERNAL_ERROR)
|
|
|
|
ret = mlx4_internal_err_ret_value(dev, op,
|
|
|
|
op_modifier);
|
|
|
|
else
|
|
|
|
mlx4_err(dev, "failed execution of VHCR_POST command opcode 0x%x\n", op);
|
|
|
|
}
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
before mlx4_multi_func_init(). However, for unlucky configurations,
mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
calls into mlx4_slave_cmd(), and that immediately tries to do
down(&priv->cmd.slave_sem);
but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
(which we haven't called yet). The next thing it tries to do is access
priv->mfunc.vhcr, but that hasn't been allocated yet.
Fix this by moving the initialization of slave_sem and vhcr up into
mlx4_cmd_init(). Also, since slave_sem is really just being used as a
mutex, convert it into a slave_cmd_mutex.
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-09-26 12:24:07 +08:00
|
|
|
|
|
|
|
mutex_unlock(&priv->cmd.slave_cmd_mutex);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
static int mlx4_cmd_poll(struct mlx4_dev *dev, u64 in_param, u64 *out_param,
|
|
|
|
int out_is_imm, u32 in_modifier, u8 op_modifier,
|
|
|
|
u16 op, unsigned long timeout)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
void __iomem *hcr = priv->cmd.hcr;
|
|
|
|
int err = 0;
|
|
|
|
unsigned long end;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
u32 stat;
|
2007-05-09 09:00:38 +08:00
|
|
|
|
|
|
|
down(&priv->cmd.poll_sem);
|
|
|
|
|
2015-01-25 22:59:39 +08:00
|
|
|
if (dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR) {
|
2012-07-20 17:55:43 +08:00
|
|
|
/*
|
|
|
|
* Device is going through error recovery
|
|
|
|
* and cannot accept commands.
|
|
|
|
*/
|
2015-01-25 22:59:39 +08:00
|
|
|
err = mlx4_internal_err_ret_value(dev, op, op_modifier);
|
2012-07-20 17:55:43 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2014-05-14 17:15:13 +08:00
|
|
|
if (out_is_imm && !out_param) {
|
|
|
|
mlx4_err(dev, "response expected while output mailbox is NULL for command 0x%x\n",
|
|
|
|
op);
|
|
|
|
err = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
err = mlx4_cmd_post(dev, in_param, out_param ? *out_param : 0,
|
|
|
|
in_modifier, op_modifier, op, CMD_POLL_TOKEN, 0);
|
|
|
|
if (err)
|
2015-01-25 22:59:39 +08:00
|
|
|
goto out_reset;
|
2007-05-09 09:00:38 +08:00
|
|
|
|
|
|
|
end = msecs_to_jiffies(timeout) + jiffies;
|
2012-07-20 17:55:43 +08:00
|
|
|
while (cmd_pending(dev) && time_before(jiffies, end)) {
|
2015-01-25 22:59:35 +08:00
|
|
|
if (pci_channel_offline(dev->persist->pdev)) {
|
2012-07-20 17:55:43 +08:00
|
|
|
/*
|
|
|
|
* Device is going through error recovery
|
|
|
|
* and cannot accept commands.
|
|
|
|
*/
|
|
|
|
err = -EIO;
|
2015-01-25 22:59:39 +08:00
|
|
|
goto out_reset;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR) {
|
|
|
|
err = mlx4_internal_err_ret_value(dev, op, op_modifier);
|
2012-07-20 17:55:43 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
cond_resched();
|
2012-07-20 17:55:43 +08:00
|
|
|
}
|
2007-05-09 09:00:38 +08:00
|
|
|
|
|
|
|
if (cmd_pending(dev)) {
|
2013-06-25 17:09:37 +08:00
|
|
|
mlx4_warn(dev, "command 0x%x timed out (go bit not cleared)\n",
|
|
|
|
op);
|
2015-01-25 22:59:39 +08:00
|
|
|
err = -EIO;
|
|
|
|
goto out_reset;
|
2007-05-09 09:00:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (out_is_imm)
|
|
|
|
*out_param =
|
|
|
|
(u64) be32_to_cpu((__force __be32)
|
|
|
|
__raw_readl(hcr + HCR_OUT_PARAM_OFFSET)) << 32 |
|
|
|
|
(u64) be32_to_cpu((__force __be32)
|
|
|
|
__raw_readl(hcr + HCR_OUT_PARAM_OFFSET + 4));
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
stat = be32_to_cpu((__force __be32)
|
|
|
|
__raw_readl(hcr + HCR_STATUS_OFFSET)) >> 24;
|
|
|
|
err = mlx4_status_to_errno(stat);
|
2015-01-25 22:59:39 +08:00
|
|
|
if (err) {
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
mlx4_err(dev, "command 0x%x failed: fw status = 0x%x\n",
|
|
|
|
op, stat);
|
2015-01-25 22:59:39 +08:00
|
|
|
if (mlx4_closing_cmd_fatal_error(op, stat))
|
|
|
|
goto out_reset;
|
|
|
|
goto out;
|
|
|
|
}
|
2007-05-09 09:00:38 +08:00
|
|
|
|
2015-01-25 22:59:39 +08:00
|
|
|
out_reset:
|
|
|
|
if (err)
|
|
|
|
err = mlx4_cmd_reset_flow(dev, op, op_modifier, err);
|
2007-05-09 09:00:38 +08:00
|
|
|
out:
|
|
|
|
up(&priv->cmd.poll_sem);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
void mlx4_cmd_event(struct mlx4_dev *dev, u16 token, u8 status, u64 out_param)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct mlx4_cmd_context *context =
|
|
|
|
&priv->cmd.context[token & priv->cmd.token_mask];
|
|
|
|
|
|
|
|
/* previously timed out command completing at long last */
|
|
|
|
if (token != context->token)
|
|
|
|
return;
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
context->fw_status = status;
|
2007-05-09 09:00:38 +08:00
|
|
|
context->result = mlx4_status_to_errno(status);
|
|
|
|
context->out_param = out_param;
|
|
|
|
|
|
|
|
complete(&context->done);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mlx4_cmd_wait(struct mlx4_dev *dev, u64 in_param, u64 *out_param,
|
|
|
|
int out_is_imm, u32 in_modifier, u8 op_modifier,
|
|
|
|
u16 op, unsigned long timeout)
|
|
|
|
{
|
|
|
|
struct mlx4_cmd *cmd = &mlx4_priv(dev)->cmd;
|
|
|
|
struct mlx4_cmd_context *context;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
down(&cmd->event_sem);
|
|
|
|
|
|
|
|
spin_lock(&cmd->context_lock);
|
|
|
|
BUG_ON(cmd->free_head < 0);
|
|
|
|
context = &cmd->context[cmd->free_head];
|
2007-07-21 12:19:43 +08:00
|
|
|
context->token += cmd->token_mask + 1;
|
2007-05-09 09:00:38 +08:00
|
|
|
cmd->free_head = context->next;
|
|
|
|
spin_unlock(&cmd->context_lock);
|
|
|
|
|
2014-05-14 17:15:13 +08:00
|
|
|
if (out_is_imm && !out_param) {
|
|
|
|
mlx4_err(dev, "response expected while output mailbox is NULL for command 0x%x\n",
|
|
|
|
op);
|
|
|
|
err = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2015-01-25 22:59:39 +08:00
|
|
|
reinit_completion(&context->done);
|
2007-05-09 09:00:38 +08:00
|
|
|
|
2015-01-25 22:59:39 +08:00
|
|
|
err = mlx4_cmd_post(dev, in_param, out_param ? *out_param : 0,
|
|
|
|
in_modifier, op_modifier, op, context->token, 1);
|
|
|
|
if (err)
|
|
|
|
goto out_reset;
|
2007-05-09 09:00:38 +08:00
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (!wait_for_completion_timeout(&context->done,
|
|
|
|
msecs_to_jiffies(timeout))) {
|
2013-06-25 17:09:37 +08:00
|
|
|
mlx4_warn(dev, "command 0x%x timed out (go bit not cleared)\n",
|
|
|
|
op);
|
2015-01-25 22:59:39 +08:00
|
|
|
err = -EIO;
|
|
|
|
goto out_reset;
|
2007-05-09 09:00:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
err = context->result;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (err) {
|
2014-09-30 17:03:50 +08:00
|
|
|
/* Since we do not want to have this error message always
|
|
|
|
* displayed at driver start when there are ConnectX2 HCAs
|
|
|
|
* on the host, we deprecate the error message for this
|
|
|
|
* specific command/input_mod/opcode_mod/fw-status to be debug.
|
|
|
|
*/
|
|
|
|
if (op == MLX4_CMD_SET_PORT && in_modifier == 1 &&
|
|
|
|
op_modifier == 0 && context->fw_status == CMD_STAT_BAD_SIZE)
|
|
|
|
mlx4_dbg(dev, "command 0x%x failed: fw status = 0x%x\n",
|
|
|
|
op, context->fw_status);
|
|
|
|
else
|
|
|
|
mlx4_err(dev, "command 0x%x failed: fw status = 0x%x\n",
|
|
|
|
op, context->fw_status);
|
2015-01-25 22:59:39 +08:00
|
|
|
if (dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR)
|
|
|
|
err = mlx4_internal_err_ret_value(dev, op, op_modifier);
|
|
|
|
else if (mlx4_closing_cmd_fatal_error(op, context->fw_status))
|
|
|
|
goto out_reset;
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
goto out;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
2007-05-09 09:00:38 +08:00
|
|
|
|
|
|
|
if (out_is_imm)
|
|
|
|
*out_param = context->out_param;
|
|
|
|
|
2015-01-25 22:59:39 +08:00
|
|
|
out_reset:
|
|
|
|
if (err)
|
|
|
|
err = mlx4_cmd_reset_flow(dev, op, op_modifier, err);
|
2007-05-09 09:00:38 +08:00
|
|
|
out:
|
|
|
|
spin_lock(&cmd->context_lock);
|
|
|
|
context->next = cmd->free_head;
|
|
|
|
cmd->free_head = context - cmd->context;
|
|
|
|
spin_unlock(&cmd->context_lock);
|
|
|
|
|
|
|
|
up(&cmd->event_sem);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __mlx4_cmd(struct mlx4_dev *dev, u64 in_param, u64 *out_param,
|
|
|
|
int out_is_imm, u32 in_modifier, u8 op_modifier,
|
2011-12-13 12:10:51 +08:00
|
|
|
u16 op, unsigned long timeout, int native)
|
2007-05-09 09:00:38 +08:00
|
|
|
{
|
2015-01-25 22:59:35 +08:00
|
|
|
if (pci_channel_offline(dev->persist->pdev))
|
2015-01-25 22:59:39 +08:00
|
|
|
return mlx4_cmd_reset_flow(dev, op, op_modifier, -EIO);
|
2012-07-20 17:55:43 +08:00
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (!mlx4_is_mfunc(dev) || (native && mlx4_is_master(dev))) {
|
2015-01-25 22:59:39 +08:00
|
|
|
if (dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR)
|
|
|
|
return mlx4_internal_err_ret_value(dev, op,
|
|
|
|
op_modifier);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (mlx4_priv(dev)->cmd.use_events)
|
|
|
|
return mlx4_cmd_wait(dev, in_param, out_param,
|
|
|
|
out_is_imm, in_modifier,
|
|
|
|
op_modifier, op, timeout);
|
|
|
|
else
|
|
|
|
return mlx4_cmd_poll(dev, in_param, out_param,
|
|
|
|
out_is_imm, in_modifier,
|
|
|
|
op_modifier, op, timeout);
|
|
|
|
}
|
|
|
|
return mlx4_slave_cmd(dev, in_param, out_param, out_is_imm,
|
|
|
|
in_modifier, op_modifier, op, timeout);
|
2007-05-09 09:00:38 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__mlx4_cmd);
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
|
2015-01-25 22:59:42 +08:00
|
|
|
int mlx4_ARM_COMM_CHANNEL(struct mlx4_dev *dev)
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
{
|
|
|
|
return mlx4_cmd(dev, 0, 0, 0, MLX4_CMD_ARM_COMM_CHANNEL,
|
|
|
|
MLX4_CMD_TIME_CLASS_B, MLX4_CMD_NATIVE);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mlx4_ACCESS_MEM(struct mlx4_dev *dev, u64 master_addr,
|
|
|
|
int slave, u64 slave_addr,
|
|
|
|
int size, int is_read)
|
|
|
|
{
|
|
|
|
u64 in_param;
|
|
|
|
u64 out_param;
|
|
|
|
|
|
|
|
if ((slave_addr & 0xfff) | (master_addr & 0xfff) |
|
|
|
|
(slave & ~0x7f) | (size & 0xff)) {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_err(dev, "Bad access mem params - slave_addr:0x%llx master_addr:0x%llx slave_id:%d size:%d\n",
|
|
|
|
slave_addr, master_addr, slave, size);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (is_read) {
|
|
|
|
in_param = (u64) slave | slave_addr;
|
|
|
|
out_param = (u64) dev->caps.function | master_addr;
|
|
|
|
} else {
|
|
|
|
in_param = (u64) dev->caps.function | master_addr;
|
|
|
|
out_param = (u64) slave | slave_addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
return mlx4_cmd_imm(dev, in_param, &out_param, size, 0,
|
|
|
|
MLX4_CMD_ACCESS_MEM,
|
|
|
|
MLX4_CMD_TIME_CLASS_A, MLX4_CMD_NATIVE);
|
|
|
|
}
|
|
|
|
|
2012-08-03 16:40:45 +08:00
|
|
|
static int query_pkey_block(struct mlx4_dev *dev, u8 port, u16 index, u16 *pkey,
|
|
|
|
struct mlx4_cmd_mailbox *inbox,
|
|
|
|
struct mlx4_cmd_mailbox *outbox)
|
|
|
|
{
|
|
|
|
struct ib_smp *in_mad = (struct ib_smp *)(inbox->buf);
|
|
|
|
struct ib_smp *out_mad = (struct ib_smp *)(outbox->buf);
|
|
|
|
int err;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (index & 0x1f)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
in_mad->attr_mod = cpu_to_be32(index / 32);
|
|
|
|
|
|
|
|
err = mlx4_cmd_box(dev, inbox->dma, outbox->dma, port, 3,
|
|
|
|
MLX4_CMD_MAD_IFC, MLX4_CMD_TIME_CLASS_C,
|
|
|
|
MLX4_CMD_NATIVE);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
for (i = 0; i < 32; ++i)
|
|
|
|
pkey[i] = be16_to_cpu(((__be16 *) out_mad->data)[i]);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int get_full_pkey_table(struct mlx4_dev *dev, u8 port, u16 *table,
|
|
|
|
struct mlx4_cmd_mailbox *inbox,
|
|
|
|
struct mlx4_cmd_mailbox *outbox)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
for (i = 0; i < dev->caps.pkey_table_len[port]; i += 32) {
|
|
|
|
err = query_pkey_block(dev, port, i, table + i, inbox, outbox);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#define PORT_CAPABILITY_LOCATION_IN_SMP 20
|
|
|
|
#define PORT_STATE_OFFSET 32
|
|
|
|
|
|
|
|
static enum ib_port_state vf_port_state(struct mlx4_dev *dev, int port, int vf)
|
|
|
|
{
|
2012-08-03 16:40:49 +08:00
|
|
|
if (mlx4_get_slave_port_state(dev, vf, port) == SLAVE_PORT_UP)
|
|
|
|
return IB_PORT_ACTIVE;
|
|
|
|
else
|
|
|
|
return IB_PORT_DOWN;
|
2012-08-03 16:40:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mlx4_MAD_IFC_wrapper(struct mlx4_dev *dev, int slave,
|
|
|
|
struct mlx4_vhcr *vhcr,
|
|
|
|
struct mlx4_cmd_mailbox *inbox,
|
|
|
|
struct mlx4_cmd_mailbox *outbox,
|
|
|
|
struct mlx4_cmd_info *cmd)
|
|
|
|
{
|
|
|
|
struct ib_smp *smp = inbox->buf;
|
|
|
|
u32 index;
|
|
|
|
u8 port;
|
2014-05-29 21:31:02 +08:00
|
|
|
u8 opcode_modifier;
|
2012-08-03 16:40:45 +08:00
|
|
|
u16 *table;
|
|
|
|
int err;
|
|
|
|
int vidx, pidx;
|
2014-05-29 21:31:02 +08:00
|
|
|
int network_view;
|
2012-08-03 16:40:45 +08:00
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct ib_smp *outsmp = outbox->buf;
|
|
|
|
__be16 *outtab = (__be16 *)(outsmp->data);
|
|
|
|
__be32 slave_cap_mask;
|
2012-08-03 16:40:56 +08:00
|
|
|
__be64 slave_node_guid;
|
2014-05-29 21:31:02 +08:00
|
|
|
|
2012-08-03 16:40:45 +08:00
|
|
|
port = vhcr->in_modifier;
|
|
|
|
|
2014-05-29 21:31:02 +08:00
|
|
|
/* network-view bit is for driver use only, and should not be passed to FW */
|
|
|
|
opcode_modifier = vhcr->op_modifier & ~0x8; /* clear netw view bit */
|
|
|
|
network_view = !!(vhcr->op_modifier & 0x8);
|
|
|
|
|
2012-08-03 16:40:45 +08:00
|
|
|
if (smp->base_version == 1 &&
|
|
|
|
smp->mgmt_class == IB_MGMT_CLASS_SUBN_LID_ROUTED &&
|
|
|
|
smp->class_version == 1) {
|
2014-05-29 21:31:02 +08:00
|
|
|
/* host view is paravirtualized */
|
|
|
|
if (!network_view && smp->method == IB_MGMT_METHOD_GET) {
|
2012-08-03 16:40:45 +08:00
|
|
|
if (smp->attr_id == IB_SMP_ATTR_PKEY_TABLE) {
|
|
|
|
index = be32_to_cpu(smp->attr_mod);
|
|
|
|
if (port < 1 || port > dev->caps.num_ports)
|
|
|
|
return -EINVAL;
|
2015-01-27 21:58:07 +08:00
|
|
|
table = kcalloc((dev->caps.pkey_table_len[port] / 32) + 1,
|
|
|
|
sizeof(*table) * 32, GFP_KERNEL);
|
|
|
|
|
2012-08-03 16:40:45 +08:00
|
|
|
if (!table)
|
|
|
|
return -ENOMEM;
|
|
|
|
/* need to get the full pkey table because the paravirtualized
|
|
|
|
* pkeys may be scattered among several pkey blocks.
|
|
|
|
*/
|
|
|
|
err = get_full_pkey_table(dev, port, table, inbox, outbox);
|
|
|
|
if (!err) {
|
|
|
|
for (vidx = index * 32; vidx < (index + 1) * 32; ++vidx) {
|
|
|
|
pidx = priv->virt2phys_pkey[slave][port - 1][vidx];
|
|
|
|
outtab[vidx % 32] = cpu_to_be16(table[pidx]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
kfree(table);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
if (smp->attr_id == IB_SMP_ATTR_PORT_INFO) {
|
|
|
|
/*get the slave specific caps:*/
|
|
|
|
/*do the command */
|
|
|
|
err = mlx4_cmd_box(dev, inbox->dma, outbox->dma,
|
2014-05-29 21:31:02 +08:00
|
|
|
vhcr->in_modifier, opcode_modifier,
|
2012-08-03 16:40:45 +08:00
|
|
|
vhcr->op, MLX4_CMD_TIME_CLASS_C, MLX4_CMD_NATIVE);
|
|
|
|
/* modify the response for slaves */
|
|
|
|
if (!err && slave != mlx4_master_func_num(dev)) {
|
|
|
|
u8 *state = outsmp->data + PORT_STATE_OFFSET;
|
|
|
|
|
|
|
|
*state = (*state & 0xf0) | vf_port_state(dev, port, slave);
|
|
|
|
slave_cap_mask = priv->mfunc.master.slave_state[slave].ib_cap_mask[port];
|
|
|
|
memcpy(outsmp->data + PORT_CAPABILITY_LOCATION_IN_SMP, &slave_cap_mask, 4);
|
|
|
|
}
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
if (smp->attr_id == IB_SMP_ATTR_GUID_INFO) {
|
|
|
|
/* compute slave's gid block */
|
|
|
|
smp->attr_mod = cpu_to_be32(slave / 8);
|
|
|
|
/* execute cmd */
|
|
|
|
err = mlx4_cmd_box(dev, inbox->dma, outbox->dma,
|
2014-05-29 21:31:02 +08:00
|
|
|
vhcr->in_modifier, opcode_modifier,
|
2012-08-03 16:40:45 +08:00
|
|
|
vhcr->op, MLX4_CMD_TIME_CLASS_C, MLX4_CMD_NATIVE);
|
|
|
|
if (!err) {
|
|
|
|
/* if needed, move slave gid to index 0 */
|
|
|
|
if (slave % 8)
|
|
|
|
memcpy(outsmp->data,
|
|
|
|
outsmp->data + (slave % 8) * 8, 8);
|
|
|
|
/* delete all other gids */
|
|
|
|
memset(outsmp->data + 8, 0, 56);
|
|
|
|
}
|
|
|
|
return err;
|
|
|
|
}
|
2012-08-03 16:40:56 +08:00
|
|
|
if (smp->attr_id == IB_SMP_ATTR_NODE_INFO) {
|
|
|
|
err = mlx4_cmd_box(dev, inbox->dma, outbox->dma,
|
2014-05-29 21:31:02 +08:00
|
|
|
vhcr->in_modifier, opcode_modifier,
|
2012-08-03 16:40:56 +08:00
|
|
|
vhcr->op, MLX4_CMD_TIME_CLASS_C, MLX4_CMD_NATIVE);
|
|
|
|
if (!err) {
|
|
|
|
slave_node_guid = mlx4_get_slave_node_guid(dev, slave);
|
|
|
|
memcpy(outsmp->data + 12, &slave_node_guid, 8);
|
|
|
|
}
|
|
|
|
return err;
|
|
|
|
}
|
2012-08-03 16:40:45 +08:00
|
|
|
}
|
|
|
|
}
|
2014-05-29 21:31:02 +08:00
|
|
|
|
|
|
|
/* Non-privileged VFs are only allowed "host" view LID-routed 'Get' MADs.
|
|
|
|
* These are the MADs used by ib verbs (such as ib_query_gids).
|
|
|
|
*/
|
2012-08-03 16:40:45 +08:00
|
|
|
if (slave != mlx4_master_func_num(dev) &&
|
2014-05-29 21:31:02 +08:00
|
|
|
!mlx4_vf_smi_enabled(dev, slave, port)) {
|
|
|
|
if (!(smp->mgmt_class == IB_MGMT_CLASS_SUBN_LID_ROUTED &&
|
|
|
|
smp->method == IB_MGMT_METHOD_GET) || network_view) {
|
|
|
|
mlx4_err(dev, "Unprivileged slave %d is trying to execute a Subnet MGMT MAD, class 0x%x, method 0x%x, view=%s for attr 0x%x. Rejecting\n",
|
|
|
|
slave, smp->method, smp->mgmt_class,
|
|
|
|
network_view ? "Network" : "Host",
|
|
|
|
be16_to_cpu(smp->attr_id));
|
|
|
|
return -EPERM;
|
|
|
|
}
|
2012-08-03 16:40:45 +08:00
|
|
|
}
|
2014-05-29 21:31:02 +08:00
|
|
|
|
2012-08-03 16:40:45 +08:00
|
|
|
return mlx4_cmd_box(dev, inbox->dma, outbox->dma,
|
2014-05-29 21:31:02 +08:00
|
|
|
vhcr->in_modifier, opcode_modifier,
|
2012-08-03 16:40:45 +08:00
|
|
|
vhcr->op, MLX4_CMD_TIME_CLASS_C, MLX4_CMD_NATIVE);
|
|
|
|
}
|
|
|
|
|
2014-03-27 20:02:02 +08:00
|
|
|
static int mlx4_CMD_EPERM_wrapper(struct mlx4_dev *dev, int slave,
|
2013-07-28 23:54:21 +08:00
|
|
|
struct mlx4_vhcr *vhcr,
|
|
|
|
struct mlx4_cmd_mailbox *inbox,
|
|
|
|
struct mlx4_cmd_mailbox *outbox,
|
|
|
|
struct mlx4_cmd_info *cmd)
|
|
|
|
{
|
|
|
|
return -EPERM;
|
|
|
|
}
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
int mlx4_DMA_wrapper(struct mlx4_dev *dev, int slave,
|
|
|
|
struct mlx4_vhcr *vhcr,
|
|
|
|
struct mlx4_cmd_mailbox *inbox,
|
|
|
|
struct mlx4_cmd_mailbox *outbox,
|
|
|
|
struct mlx4_cmd_info *cmd)
|
|
|
|
{
|
|
|
|
u64 in_param;
|
|
|
|
u64 out_param;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
in_param = cmd->has_inbox ? (u64) inbox->dma : vhcr->in_param;
|
|
|
|
out_param = cmd->has_outbox ? (u64) outbox->dma : vhcr->out_param;
|
|
|
|
if (cmd->encode_slave_id) {
|
|
|
|
in_param &= 0xffffffffffffff00ll;
|
|
|
|
in_param |= slave;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = __mlx4_cmd(dev, in_param, &out_param, cmd->out_is_imm,
|
|
|
|
vhcr->in_modifier, vhcr->op_modifier, vhcr->op,
|
|
|
|
MLX4_CMD_TIME_CLASS_A, MLX4_CMD_NATIVE);
|
|
|
|
|
|
|
|
if (cmd->out_is_imm)
|
|
|
|
vhcr->out_param = out_param;
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct mlx4_cmd_info cmd_info[] = {
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_FW,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2012-05-30 17:14:53 +08:00
|
|
|
.wrapper = mlx4_QUERY_FW_wrapper
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_HCA,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = NULL
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_DEV_CAP,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2012-05-30 17:14:53 +08:00
|
|
|
.wrapper = mlx4_QUERY_DEV_CAP_wrapper
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
},
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_FUNC_CAP,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_QUERY_FUNC_CAP_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_ADAPTER,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = NULL
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_INIT_PORT,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_INIT_PORT_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_CLOSE_PORT,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_CLOSE_PORT_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_PORT,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_QUERY_PORT_wrapper
|
|
|
|
},
|
2011-12-13 12:16:21 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SET_PORT,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_SET_PORT_wrapper
|
|
|
|
},
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_MAP_EQ,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_MAP_EQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SW2HW_EQ,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = true,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_SW2HW_EQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_HW_HEALTH_CHECK,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = NULL
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_NOP,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = NULL
|
|
|
|
},
|
2014-03-27 20:02:03 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_CONFIG_DEV,
|
|
|
|
.has_inbox = false,
|
2014-11-02 22:26:17 +08:00
|
|
|
.has_outbox = true,
|
2014-03-27 20:02:03 +08:00
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2014-11-02 22:26:17 +08:00
|
|
|
.wrapper = mlx4_CONFIG_DEV_wrapper
|
2014-03-27 20:02:03 +08:00
|
|
|
},
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_ALLOC_RES,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = true,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_ALLOC_RES_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_FREE_RES,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_FREE_RES_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SW2HW_MPT,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = true,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_SW2HW_MPT_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_MPT,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_QUERY_MPT_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_HW2SW_MPT,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_HW2SW_MPT_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_READ_MTT,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = NULL
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_WRITE_MTT,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_WRITE_MTT_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SYNC_TPT,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = NULL
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_HW2SW_EQ,
|
|
|
|
.has_inbox = false,
|
2015-01-27 21:58:03 +08:00
|
|
|
.has_outbox = false,
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = true,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_HW2SW_EQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_EQ,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = true,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_QUERY_EQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SW2HW_CQ,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = true,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_SW2HW_CQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_HW2SW_CQ,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_HW2SW_CQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_CQ,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_QUERY_CQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_MODIFY_CQ,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = true,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_MODIFY_CQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SW2HW_SRQ,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = true,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_SW2HW_SRQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_HW2SW_SRQ,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_HW2SW_SRQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_SRQ,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_QUERY_SRQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_ARM_SRQ,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_ARM_SRQ_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_RST2INIT_QP,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = true,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_RST2INIT_QP_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_INIT2INIT_QP,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2012-08-03 16:40:43 +08:00
|
|
|
.wrapper = mlx4_INIT2INIT_QP_wrapper
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_INIT2RTR_QP,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_INIT2RTR_QP_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_RTR2RTS_QP,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2012-08-03 16:40:43 +08:00
|
|
|
.wrapper = mlx4_RTR2RTS_QP_wrapper
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_RTS2RTS_QP,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2012-08-03 16:40:43 +08:00
|
|
|
.wrapper = mlx4_RTS2RTS_QP_wrapper
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SQERR2RTS_QP,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2012-08-03 16:40:43 +08:00
|
|
|
.wrapper = mlx4_SQERR2RTS_QP_wrapper
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_2ERR_QP,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_GEN_QP_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_RTS2SQD_QP,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_GEN_QP_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SQD2SQD_QP,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2012-08-03 16:40:43 +08:00
|
|
|
.wrapper = mlx4_SQD2SQD_QP_wrapper
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SQD2RTS_QP,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2012-08-03 16:40:43 +08:00
|
|
|
.wrapper = mlx4_SQD2RTS_QP_wrapper
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_2RST_QP,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_2RST_QP_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_QP,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_GEN_QP_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SUSPEND_QP,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_GEN_QP_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_UNSUSPEND_QP,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_GEN_QP_wrapper
|
|
|
|
},
|
2013-06-28 00:05:21 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_UPDATE_QP,
|
2014-05-15 20:29:27 +08:00
|
|
|
.has_inbox = true,
|
2013-06-28 00:05:21 +08:00
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2014-05-15 20:29:27 +08:00
|
|
|
.wrapper = mlx4_UPDATE_QP_wrapper
|
2013-06-28 00:05:21 +08:00
|
|
|
},
|
2013-07-28 23:54:21 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_GET_OP_REQ,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2014-03-27 20:02:02 +08:00
|
|
|
.wrapper = mlx4_CMD_EPERM_wrapper,
|
2013-07-28 23:54:21 +08:00
|
|
|
},
|
2012-08-03 16:40:45 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_CONF_SPECIAL_QP,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL, /* XXX verify: only demux can do this */
|
|
|
|
.wrapper = NULL
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_MAD_IFC,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_MAD_IFC_wrapper
|
|
|
|
},
|
2014-06-01 16:53:50 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_MAD_DEMUX,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_CMD_EPERM_wrapper
|
|
|
|
},
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QUERY_IF_STAT,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_QUERY_IF_STAT_wrapper
|
|
|
|
},
|
2014-10-27 17:37:37 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_ACCESS_REG,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2014-11-02 22:26:13 +08:00
|
|
|
.wrapper = mlx4_ACCESS_REG_wrapper,
|
2014-10-27 17:37:37 +08:00
|
|
|
},
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
/* Native multicast commands are not available for guests */
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_QP_ATTACH,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_QP_ATTACH_wrapper
|
|
|
|
},
|
2011-12-13 12:16:02 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_PROMISC,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_PROMISC_wrapper
|
|
|
|
},
|
2011-12-13 12:16:21 +08:00
|
|
|
/* Ethernet specific commands */
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SET_VLAN_FLTR,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_SET_VLAN_FLTR_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_SET_MCAST_FLTR,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_SET_MCAST_FLTR_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_DUMP_ETH_STATS,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = true,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_DUMP_ETH_STATS_wrapper
|
|
|
|
},
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_CMD_INFORM_FLR_DONE,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = NULL
|
|
|
|
},
|
2012-07-05 12:03:45 +08:00
|
|
|
/* flow steering commands */
|
|
|
|
{
|
|
|
|
.opcode = MLX4_QP_FLOW_STEERING_ATTACH,
|
|
|
|
.has_inbox = true,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = true,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_QP_FLOW_STEERING_ATTACH_wrapper
|
|
|
|
},
|
|
|
|
{
|
|
|
|
.opcode = MLX4_QP_FLOW_STEERING_DETACH,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
|
|
|
.wrapper = mlx4_QP_FLOW_STEERING_DETACH_wrapper
|
|
|
|
},
|
2013-11-07 21:25:14 +08:00
|
|
|
{
|
|
|
|
.opcode = MLX4_FLOW_STEERING_IB_UC_QP_RANGE,
|
|
|
|
.has_inbox = false,
|
|
|
|
.has_outbox = false,
|
|
|
|
.out_is_imm = false,
|
|
|
|
.encode_slave_id = false,
|
|
|
|
.verify = NULL,
|
2014-03-27 20:02:02 +08:00
|
|
|
.wrapper = mlx4_CMD_EPERM_wrapper
|
2013-11-07 21:25:14 +08:00
|
|
|
},
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static int mlx4_master_process_vhcr(struct mlx4_dev *dev, int slave,
|
|
|
|
struct mlx4_vhcr_cmd *in_vhcr)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct mlx4_cmd_info *cmd = NULL;
|
|
|
|
struct mlx4_vhcr_cmd *vhcr_cmd = in_vhcr ? in_vhcr : priv->mfunc.vhcr;
|
|
|
|
struct mlx4_vhcr *vhcr;
|
|
|
|
struct mlx4_cmd_mailbox *inbox = NULL;
|
|
|
|
struct mlx4_cmd_mailbox *outbox = NULL;
|
|
|
|
u64 in_param;
|
|
|
|
u64 out_param;
|
|
|
|
int ret = 0;
|
|
|
|
int i;
|
2011-12-19 12:03:53 +08:00
|
|
|
int err = 0;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
|
|
|
|
/* Create sw representation of Virtual HCR */
|
|
|
|
vhcr = kzalloc(sizeof(struct mlx4_vhcr), GFP_KERNEL);
|
|
|
|
if (!vhcr)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* DMA in the vHCR */
|
|
|
|
if (!in_vhcr) {
|
|
|
|
ret = mlx4_ACCESS_MEM(dev, priv->mfunc.vhcr_dma, slave,
|
|
|
|
priv->mfunc.master.slave_state[slave].vhcr_dma,
|
|
|
|
ALIGN(sizeof(struct mlx4_vhcr_cmd),
|
|
|
|
MLX4_ACCESS_MEM_ALIGN), 1);
|
|
|
|
if (ret) {
|
2015-01-25 22:59:43 +08:00
|
|
|
if (!(dev->persist->state &
|
|
|
|
MLX4_DEVICE_STATE_INTERNAL_ERROR))
|
|
|
|
mlx4_err(dev, "%s: Failed reading vhcr ret: 0x%x\n",
|
|
|
|
__func__, ret);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
kfree(vhcr);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Fill SW VHCR fields */
|
|
|
|
vhcr->in_param = be64_to_cpu(vhcr_cmd->in_param);
|
|
|
|
vhcr->out_param = be64_to_cpu(vhcr_cmd->out_param);
|
|
|
|
vhcr->in_modifier = be32_to_cpu(vhcr_cmd->in_modifier);
|
|
|
|
vhcr->token = be16_to_cpu(vhcr_cmd->token);
|
|
|
|
vhcr->op = be16_to_cpu(vhcr_cmd->opcode) & 0xfff;
|
|
|
|
vhcr->op_modifier = (u8) (be16_to_cpu(vhcr_cmd->opcode) >> 12);
|
|
|
|
vhcr->e_bit = vhcr_cmd->flags & (1 << 6);
|
|
|
|
|
|
|
|
/* Lookup command */
|
|
|
|
for (i = 0; i < ARRAY_SIZE(cmd_info); ++i) {
|
|
|
|
if (vhcr->op == cmd_info[i].opcode) {
|
|
|
|
cmd = &cmd_info[i];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!cmd) {
|
|
|
|
mlx4_err(dev, "Unknown command:0x%x accepted from slave:%d\n",
|
|
|
|
vhcr->op, slave);
|
2011-12-19 12:03:53 +08:00
|
|
|
vhcr_cmd->status = CMD_STAT_BAD_PARAM;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
goto out_status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read inbox */
|
|
|
|
if (cmd->has_inbox) {
|
|
|
|
vhcr->in_param &= INBOX_MASK;
|
|
|
|
inbox = mlx4_alloc_cmd_mailbox(dev);
|
|
|
|
if (IS_ERR(inbox)) {
|
2011-12-19 12:03:53 +08:00
|
|
|
vhcr_cmd->status = CMD_STAT_BAD_SIZE;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
inbox = NULL;
|
2011-12-19 12:03:53 +08:00
|
|
|
goto out_status;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
|
|
|
|
2015-01-25 22:59:43 +08:00
|
|
|
ret = mlx4_ACCESS_MEM(dev, inbox->dma, slave,
|
|
|
|
vhcr->in_param,
|
|
|
|
MLX4_MAILBOX_SIZE, 1);
|
|
|
|
if (ret) {
|
|
|
|
if (!(dev->persist->state &
|
|
|
|
MLX4_DEVICE_STATE_INTERNAL_ERROR))
|
|
|
|
mlx4_err(dev, "%s: Failed reading inbox (cmd:0x%x)\n",
|
|
|
|
__func__, cmd->opcode);
|
2011-12-19 12:03:53 +08:00
|
|
|
vhcr_cmd->status = CMD_STAT_INTERNAL_ERR;
|
|
|
|
goto out_status;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Apply permission and bound checks if applicable */
|
|
|
|
if (cmd->verify && cmd->verify(dev, slave, vhcr, inbox)) {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_warn(dev, "Command:0x%x from slave: %d failed protection checks for resource_id:%d\n",
|
|
|
|
vhcr->op, slave, vhcr->in_modifier);
|
2011-12-19 12:03:53 +08:00
|
|
|
vhcr_cmd->status = CMD_STAT_BAD_OP;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
goto out_status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allocate outbox */
|
|
|
|
if (cmd->has_outbox) {
|
|
|
|
outbox = mlx4_alloc_cmd_mailbox(dev);
|
|
|
|
if (IS_ERR(outbox)) {
|
2011-12-19 12:03:53 +08:00
|
|
|
vhcr_cmd->status = CMD_STAT_BAD_SIZE;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
outbox = NULL;
|
2011-12-19 12:03:53 +08:00
|
|
|
goto out_status;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Execute the command! */
|
|
|
|
if (cmd->wrapper) {
|
2011-12-19 12:03:53 +08:00
|
|
|
err = cmd->wrapper(dev, slave, vhcr, inbox, outbox,
|
|
|
|
cmd);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (cmd->out_is_imm)
|
|
|
|
vhcr_cmd->out_param = cpu_to_be64(vhcr->out_param);
|
|
|
|
} else {
|
|
|
|
in_param = cmd->has_inbox ? (u64) inbox->dma :
|
|
|
|
vhcr->in_param;
|
|
|
|
out_param = cmd->has_outbox ? (u64) outbox->dma :
|
|
|
|
vhcr->out_param;
|
2011-12-19 12:03:53 +08:00
|
|
|
err = __mlx4_cmd(dev, in_param, &out_param,
|
|
|
|
cmd->out_is_imm, vhcr->in_modifier,
|
|
|
|
vhcr->op_modifier, vhcr->op,
|
|
|
|
MLX4_CMD_TIME_CLASS_A,
|
|
|
|
MLX4_CMD_NATIVE);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
|
|
|
|
if (cmd->out_is_imm) {
|
|
|
|
vhcr->out_param = out_param;
|
|
|
|
vhcr_cmd->out_param = cpu_to_be64(vhcr->out_param);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-19 12:03:53 +08:00
|
|
|
if (err) {
|
2015-01-25 22:59:43 +08:00
|
|
|
if (!(dev->persist->state & MLX4_DEVICE_STATE_INTERNAL_ERROR))
|
|
|
|
mlx4_warn(dev, "vhcr command:0x%x slave:%d failed with error:%d, status %d\n",
|
|
|
|
vhcr->op, slave, vhcr->errno, err);
|
2011-12-19 12:03:53 +08:00
|
|
|
vhcr_cmd->status = mlx4_errno_to_status(err);
|
|
|
|
goto out_status;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
/* Write outbox if command completed successfully */
|
2011-12-19 12:03:53 +08:00
|
|
|
if (cmd->has_outbox && !vhcr_cmd->status) {
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
ret = mlx4_ACCESS_MEM(dev, outbox->dma, slave,
|
|
|
|
vhcr->out_param,
|
|
|
|
MLX4_MAILBOX_SIZE, MLX4_CMD_WRAPPED);
|
|
|
|
if (ret) {
|
2011-12-19 12:03:53 +08:00
|
|
|
/* If we failed to write back the outbox after the
|
|
|
|
*command was successfully executed, we must fail this
|
|
|
|
* slave, as it is now in undefined state */
|
2015-01-25 22:59:43 +08:00
|
|
|
if (!(dev->persist->state &
|
|
|
|
MLX4_DEVICE_STATE_INTERNAL_ERROR))
|
|
|
|
mlx4_err(dev, "%s:Failed writing outbox\n", __func__);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
out_status:
|
|
|
|
/* DMA back vhcr result */
|
|
|
|
if (!in_vhcr) {
|
|
|
|
ret = mlx4_ACCESS_MEM(dev, priv->mfunc.vhcr_dma, slave,
|
|
|
|
priv->mfunc.master.slave_state[slave].vhcr_dma,
|
|
|
|
ALIGN(sizeof(struct mlx4_vhcr),
|
|
|
|
MLX4_ACCESS_MEM_ALIGN),
|
|
|
|
MLX4_CMD_WRAPPED);
|
|
|
|
if (ret)
|
|
|
|
mlx4_err(dev, "%s:Failed writing vhcr result\n",
|
|
|
|
__func__);
|
|
|
|
else if (vhcr->e_bit &&
|
|
|
|
mlx4_GEN_EQE(dev, slave, &priv->mfunc.master.cmd_eqe))
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_warn(dev, "Failed to generate command completion eqe for slave %d\n",
|
|
|
|
slave);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
kfree(vhcr);
|
|
|
|
mlx4_free_cmd_mailbox(dev, inbox);
|
|
|
|
mlx4_free_cmd_mailbox(dev, outbox);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-08-05 17:04:51 +08:00
|
|
|
static int mlx4_master_immediate_activate_vlan_qos(struct mlx4_priv *priv,
|
2013-06-28 00:05:21 +08:00
|
|
|
int slave, int port)
|
|
|
|
{
|
|
|
|
struct mlx4_vport_oper_state *vp_oper;
|
|
|
|
struct mlx4_vport_state *vp_admin;
|
|
|
|
struct mlx4_vf_immed_vlan_work *work;
|
2013-06-28 00:05:22 +08:00
|
|
|
struct mlx4_dev *dev = &(priv->dev);
|
2013-06-28 00:05:21 +08:00
|
|
|
int err;
|
|
|
|
int admin_vlan_ix = NO_INDX;
|
|
|
|
|
|
|
|
vp_oper = &priv->mfunc.master.vf_oper[slave].vport[port];
|
|
|
|
vp_admin = &priv->mfunc.master.vf_admin[slave].vport[port];
|
|
|
|
|
|
|
|
if (vp_oper->state.default_vlan == vp_admin->default_vlan &&
|
2013-06-28 00:05:22 +08:00
|
|
|
vp_oper->state.default_qos == vp_admin->default_qos &&
|
|
|
|
vp_oper->state.link_state == vp_admin->link_state)
|
2013-06-28 00:05:21 +08:00
|
|
|
return 0;
|
|
|
|
|
2013-06-28 00:05:22 +08:00
|
|
|
if (!(priv->mfunc.master.slave_state[slave].active &&
|
2013-11-07 18:19:51 +08:00
|
|
|
dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_UPDATE_QP)) {
|
2013-06-28 00:05:22 +08:00
|
|
|
/* even if the UPDATE_QP command isn't supported, we still want
|
|
|
|
* to set this VF link according to the admin directive
|
|
|
|
*/
|
|
|
|
vp_oper->state.link_state = vp_admin->link_state;
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
mlx4_dbg(dev, "updating immediately admin params slave %d port %d\n",
|
|
|
|
slave, port);
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_dbg(dev, "vlan %d QoS %d link down %d\n",
|
|
|
|
vp_admin->default_vlan, vp_admin->default_qos,
|
|
|
|
vp_admin->link_state);
|
2013-06-28 00:05:22 +08:00
|
|
|
|
2013-06-28 00:05:21 +08:00
|
|
|
work = kzalloc(sizeof(*work), GFP_KERNEL);
|
|
|
|
if (!work)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
if (vp_oper->state.default_vlan != vp_admin->default_vlan) {
|
2013-11-07 18:19:51 +08:00
|
|
|
if (MLX4_VGT != vp_admin->default_vlan) {
|
|
|
|
err = __mlx4_register_vlan(&priv->dev, port,
|
|
|
|
vp_admin->default_vlan,
|
|
|
|
&admin_vlan_ix);
|
|
|
|
if (err) {
|
|
|
|
kfree(work);
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_warn(&priv->dev,
|
2013-11-07 18:19:51 +08:00
|
|
|
"No vlan resources slave %d, port %d\n",
|
|
|
|
slave, port);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
admin_vlan_ix = NO_INDX;
|
2013-06-28 00:05:21 +08:00
|
|
|
}
|
|
|
|
work->flags |= MLX4_VF_IMMED_VLAN_FLAG_VLAN;
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_dbg(&priv->dev,
|
2013-06-28 00:05:21 +08:00
|
|
|
"alloc vlan %d idx %d slave %d port %d\n",
|
|
|
|
(int)(vp_admin->default_vlan),
|
|
|
|
admin_vlan_ix, slave, port);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* save original vlan ix and vlan id */
|
|
|
|
work->orig_vlan_id = vp_oper->state.default_vlan;
|
|
|
|
work->orig_vlan_ix = vp_oper->vlan_idx;
|
|
|
|
|
|
|
|
/* handle new qos */
|
|
|
|
if (vp_oper->state.default_qos != vp_admin->default_qos)
|
|
|
|
work->flags |= MLX4_VF_IMMED_VLAN_FLAG_QOS;
|
|
|
|
|
|
|
|
if (work->flags & MLX4_VF_IMMED_VLAN_FLAG_VLAN)
|
|
|
|
vp_oper->vlan_idx = admin_vlan_ix;
|
|
|
|
|
|
|
|
vp_oper->state.default_vlan = vp_admin->default_vlan;
|
|
|
|
vp_oper->state.default_qos = vp_admin->default_qos;
|
2013-06-28 00:05:22 +08:00
|
|
|
vp_oper->state.link_state = vp_admin->link_state;
|
|
|
|
|
|
|
|
if (vp_admin->link_state == IFLA_VF_LINK_STATE_DISABLE)
|
|
|
|
work->flags |= MLX4_VF_IMMED_VLAN_FLAG_LINK_DISABLE;
|
2013-06-28 00:05:21 +08:00
|
|
|
|
|
|
|
/* iterate over QPs owned by this slave, using UPDATE_QP */
|
|
|
|
work->port = port;
|
|
|
|
work->slave = slave;
|
|
|
|
work->qos = vp_oper->state.default_qos;
|
|
|
|
work->vlan_id = vp_oper->state.default_vlan;
|
|
|
|
work->vlan_ix = vp_oper->vlan_idx;
|
|
|
|
work->priv = priv;
|
|
|
|
INIT_WORK(&work->work, mlx4_vf_immed_vlan_work_handler);
|
|
|
|
queue_work(priv->mfunc.master.comm_wq, &work->work);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-04-25 13:22:26 +08:00
|
|
|
static int mlx4_master_activate_admin_state(struct mlx4_priv *priv, int slave)
|
|
|
|
{
|
2013-04-25 13:22:28 +08:00
|
|
|
int port, err;
|
|
|
|
struct mlx4_vport_state *vp_admin;
|
|
|
|
struct mlx4_vport_oper_state *vp_oper;
|
2014-03-20 00:11:52 +08:00
|
|
|
struct mlx4_active_ports actv_ports = mlx4_get_active_ports(
|
|
|
|
&priv->dev, slave);
|
|
|
|
int min_port = find_first_bit(actv_ports.ports,
|
|
|
|
priv->dev.caps.num_ports) + 1;
|
|
|
|
int max_port = min_port - 1 +
|
|
|
|
bitmap_weight(actv_ports.ports, priv->dev.caps.num_ports);
|
|
|
|
|
|
|
|
for (port = min_port; port <= max_port; port++) {
|
|
|
|
if (!test_bit(port - 1, actv_ports.ports))
|
|
|
|
continue;
|
2014-05-29 21:31:03 +08:00
|
|
|
priv->mfunc.master.vf_oper[slave].smi_enabled[port] =
|
|
|
|
priv->mfunc.master.vf_admin[slave].enable_smi[port];
|
2013-04-25 13:22:28 +08:00
|
|
|
vp_oper = &priv->mfunc.master.vf_oper[slave].vport[port];
|
|
|
|
vp_admin = &priv->mfunc.master.vf_admin[slave].vport[port];
|
|
|
|
vp_oper->state = *vp_admin;
|
|
|
|
if (MLX4_VGT != vp_admin->default_vlan) {
|
|
|
|
err = __mlx4_register_vlan(&priv->dev, port,
|
|
|
|
vp_admin->default_vlan, &(vp_oper->vlan_idx));
|
|
|
|
if (err) {
|
|
|
|
vp_oper->vlan_idx = NO_INDX;
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_warn(&priv->dev,
|
2014-08-29 22:37:33 +08:00
|
|
|
"No vlan resources slave %d, port %d\n",
|
2013-04-25 13:22:28 +08:00
|
|
|
slave, port);
|
|
|
|
return err;
|
|
|
|
}
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_dbg(&priv->dev, "alloc vlan %d idx %d slave %d port %d\n",
|
2013-04-25 13:22:28 +08:00
|
|
|
(int)(vp_oper->state.default_vlan),
|
|
|
|
vp_oper->vlan_idx, slave, port);
|
|
|
|
}
|
2013-04-25 13:22:29 +08:00
|
|
|
if (vp_admin->spoofchk) {
|
|
|
|
vp_oper->mac_idx = __mlx4_register_mac(&priv->dev,
|
|
|
|
port,
|
|
|
|
vp_admin->mac);
|
|
|
|
if (0 > vp_oper->mac_idx) {
|
|
|
|
err = vp_oper->mac_idx;
|
|
|
|
vp_oper->mac_idx = NO_INDX;
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_warn(&priv->dev,
|
2014-08-29 22:37:33 +08:00
|
|
|
"No mac resources slave %d, port %d\n",
|
2013-04-25 13:22:29 +08:00
|
|
|
slave, port);
|
|
|
|
return err;
|
|
|
|
}
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_dbg(&priv->dev, "alloc mac %llx idx %d slave %d port %d\n",
|
2013-04-25 13:22:29 +08:00
|
|
|
vp_oper->state.mac, vp_oper->mac_idx, slave, port);
|
|
|
|
}
|
2013-04-25 13:22:26 +08:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-04-25 13:22:28 +08:00
|
|
|
static void mlx4_master_deactivate_admin_state(struct mlx4_priv *priv, int slave)
|
|
|
|
{
|
|
|
|
int port;
|
|
|
|
struct mlx4_vport_oper_state *vp_oper;
|
2014-03-20 00:11:52 +08:00
|
|
|
struct mlx4_active_ports actv_ports = mlx4_get_active_ports(
|
|
|
|
&priv->dev, slave);
|
|
|
|
int min_port = find_first_bit(actv_ports.ports,
|
|
|
|
priv->dev.caps.num_ports) + 1;
|
|
|
|
int max_port = min_port - 1 +
|
|
|
|
bitmap_weight(actv_ports.ports, priv->dev.caps.num_ports);
|
|
|
|
|
2013-04-25 13:22:28 +08:00
|
|
|
|
2014-03-20 00:11:52 +08:00
|
|
|
for (port = min_port; port <= max_port; port++) {
|
|
|
|
if (!test_bit(port - 1, actv_ports.ports))
|
|
|
|
continue;
|
2014-05-29 21:31:03 +08:00
|
|
|
priv->mfunc.master.vf_oper[slave].smi_enabled[port] =
|
|
|
|
MLX4_VF_SMI_DISABLED;
|
2013-04-25 13:22:28 +08:00
|
|
|
vp_oper = &priv->mfunc.master.vf_oper[slave].vport[port];
|
|
|
|
if (NO_INDX != vp_oper->vlan_idx) {
|
|
|
|
__mlx4_unregister_vlan(&priv->dev,
|
2013-11-03 16:03:19 +08:00
|
|
|
port, vp_oper->state.default_vlan);
|
2013-04-25 13:22:28 +08:00
|
|
|
vp_oper->vlan_idx = NO_INDX;
|
|
|
|
}
|
2013-04-25 13:22:29 +08:00
|
|
|
if (NO_INDX != vp_oper->mac_idx) {
|
2013-11-03 16:04:07 +08:00
|
|
|
__mlx4_unregister_mac(&priv->dev, port, vp_oper->state.mac);
|
2013-04-25 13:22:29 +08:00
|
|
|
vp_oper->mac_idx = NO_INDX;
|
|
|
|
}
|
2013-04-25 13:22:28 +08:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
static void mlx4_master_do_cmd(struct mlx4_dev *dev, int slave, u8 cmd,
|
|
|
|
u16 param, u8 toggle)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct mlx4_slave_state *slave_state = priv->mfunc.master.slave_state;
|
|
|
|
u32 reply;
|
|
|
|
u8 is_going_down = 0;
|
2012-01-19 17:45:46 +08:00
|
|
|
int i;
|
2012-11-28 00:24:30 +08:00
|
|
|
unsigned long flags;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
|
|
|
|
slave_state[slave].comm_toggle ^= 1;
|
|
|
|
reply = (u32) slave_state[slave].comm_toggle << 31;
|
|
|
|
if (toggle != slave_state[slave].comm_toggle) {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_warn(dev, "Incorrect toggle %d from slave %d. *** MASTER STATE COMPROMISED ***\n",
|
|
|
|
toggle, slave);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
goto reset_slave;
|
|
|
|
}
|
|
|
|
if (cmd == MLX4_COMM_CMD_RESET) {
|
|
|
|
mlx4_warn(dev, "Received reset from slave:%d\n", slave);
|
|
|
|
slave_state[slave].active = false;
|
net/mlx4_core: Don't fail reg/unreg vlan for older guests
In upstream kernels under SRIOV, the vlan register/unregister calls
were NOPs (doing nothing and returning OK). We detect these old
calls from guests (via the comm channel), since previously the
port number in mlx4_register_vlan was passed (improperly) in the
out_param. This has been corrected so that the port number is now
passed in bits 8..15 of the in_modifier field.
For old calls, these bits will be zero, so if the passed port
number is zero, we can still look at the out_param field to see
if it contains a valid port number. If yes, the VM is running
an old driver.
Since for old drivers, the register/unregister_vlan wrappers were
NOPs, we continue this policy -- the reason being that upstream
had an additional bug in eth driver running on guests (where
procedure mlx4_en_vlan_rx_kill_vid() had the following code:
if (!mlx4_find_cached_vlan(mdev->dev, priv->port, vid, &idx))
mlx4_unregister_vlan(mdev->dev, priv->port, idx);
else
en_err(priv, "could not find vid %d in cache\n", vid);
On a VM, mlx4_find_cached_vlan() will always fail, since the
vlan cache is located on the Hypervisor; on guests it is empty.
Therefore, if we allow upstream guests to register vlans, we will
have vlan leakage since the unregister will never be performed.
Leaving vlan reg/unreg for old guest drivers as a NOP is not a
feature regression, since in upstream the register/unregister
vlan wrapper is a NOP.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-03 16:03:21 +08:00
|
|
|
slave_state[slave].old_vlan_api = false;
|
2013-04-25 13:22:28 +08:00
|
|
|
mlx4_master_deactivate_admin_state(priv, slave);
|
2012-01-19 17:45:46 +08:00
|
|
|
for (i = 0; i < MLX4_EVENT_TYPES_NUM; ++i) {
|
|
|
|
slave_state[slave].event_eq[i].eqn = -1;
|
|
|
|
slave_state[slave].event_eq[i].token = 0;
|
|
|
|
}
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
/*check if we are in the middle of FLR process,
|
|
|
|
if so return "retry" status to the slave*/
|
2012-05-15 18:34:57 +08:00
|
|
|
if (MLX4_COMM_CMD_FLR == slave_state[slave].last_cmd)
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
goto inform_slave_state;
|
|
|
|
|
2012-08-03 16:40:42 +08:00
|
|
|
mlx4_dispatch_event(dev, MLX4_DEV_EVENT_SLAVE_SHUTDOWN, slave);
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
/* write the version in the event field */
|
|
|
|
reply |= mlx4_comm_get_version();
|
|
|
|
|
|
|
|
goto reset_slave;
|
|
|
|
}
|
|
|
|
/*command from slave in the middle of FLR*/
|
|
|
|
if (cmd != MLX4_COMM_CMD_RESET &&
|
|
|
|
MLX4_COMM_CMD_FLR == slave_state[slave].last_cmd) {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_warn(dev, "slave:%d is Trying to run cmd(0x%x) in the middle of FLR\n",
|
|
|
|
slave, cmd);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (cmd) {
|
|
|
|
case MLX4_COMM_CMD_VHCR0:
|
|
|
|
if (slave_state[slave].last_cmd != MLX4_COMM_CMD_RESET)
|
|
|
|
goto reset_slave;
|
|
|
|
slave_state[slave].vhcr_dma = ((u64) param) << 48;
|
|
|
|
priv->mfunc.master.slave_state[slave].cookie = 0;
|
|
|
|
mutex_init(&priv->mfunc.master.gen_eqe_mutex[slave]);
|
|
|
|
break;
|
|
|
|
case MLX4_COMM_CMD_VHCR1:
|
|
|
|
if (slave_state[slave].last_cmd != MLX4_COMM_CMD_VHCR0)
|
|
|
|
goto reset_slave;
|
|
|
|
slave_state[slave].vhcr_dma |= ((u64) param) << 32;
|
|
|
|
break;
|
|
|
|
case MLX4_COMM_CMD_VHCR2:
|
|
|
|
if (slave_state[slave].last_cmd != MLX4_COMM_CMD_VHCR1)
|
|
|
|
goto reset_slave;
|
|
|
|
slave_state[slave].vhcr_dma |= ((u64) param) << 16;
|
|
|
|
break;
|
|
|
|
case MLX4_COMM_CMD_VHCR_EN:
|
|
|
|
if (slave_state[slave].last_cmd != MLX4_COMM_CMD_VHCR2)
|
|
|
|
goto reset_slave;
|
|
|
|
slave_state[slave].vhcr_dma |= param;
|
2013-04-25 13:22:28 +08:00
|
|
|
if (mlx4_master_activate_admin_state(priv, slave))
|
|
|
|
goto reset_slave;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
slave_state[slave].active = true;
|
2012-08-03 16:40:42 +08:00
|
|
|
mlx4_dispatch_event(dev, MLX4_DEV_EVENT_SLAVE_INIT, slave);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
break;
|
|
|
|
case MLX4_COMM_CMD_VHCR_POST:
|
|
|
|
if ((slave_state[slave].last_cmd != MLX4_COMM_CMD_VHCR_EN) &&
|
2015-01-25 22:59:42 +08:00
|
|
|
(slave_state[slave].last_cmd != MLX4_COMM_CMD_VHCR_POST)) {
|
|
|
|
mlx4_warn(dev, "slave:%d is out of sync, cmd=0x%x, last command=0x%x, reset is needed\n",
|
|
|
|
slave, cmd, slave_state[slave].last_cmd);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
goto reset_slave;
|
2015-01-25 22:59:42 +08:00
|
|
|
}
|
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
before mlx4_multi_func_init(). However, for unlucky configurations,
mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
calls into mlx4_slave_cmd(), and that immediately tries to do
down(&priv->cmd.slave_sem);
but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
(which we haven't called yet). The next thing it tries to do is access
priv->mfunc.vhcr, but that hasn't been allocated yet.
Fix this by moving the initialization of slave_sem and vhcr up into
mlx4_cmd_init(). Also, since slave_sem is really just being used as a
mutex, convert it into a slave_cmd_mutex.
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-09-26 12:24:07 +08:00
|
|
|
|
|
|
|
mutex_lock(&priv->cmd.slave_cmd_mutex);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (mlx4_master_process_vhcr(dev, slave, NULL)) {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_err(dev, "Failed processing vhcr for slave:%d, resetting slave\n",
|
|
|
|
slave);
|
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
before mlx4_multi_func_init(). However, for unlucky configurations,
mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
calls into mlx4_slave_cmd(), and that immediately tries to do
down(&priv->cmd.slave_sem);
but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
(which we haven't called yet). The next thing it tries to do is access
priv->mfunc.vhcr, but that hasn't been allocated yet.
Fix this by moving the initialization of slave_sem and vhcr up into
mlx4_cmd_init(). Also, since slave_sem is really just being used as a
mutex, convert it into a slave_cmd_mutex.
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-09-26 12:24:07 +08:00
|
|
|
mutex_unlock(&priv->cmd.slave_cmd_mutex);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
goto reset_slave;
|
|
|
|
}
|
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
before mlx4_multi_func_init(). However, for unlucky configurations,
mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
calls into mlx4_slave_cmd(), and that immediately tries to do
down(&priv->cmd.slave_sem);
but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
(which we haven't called yet). The next thing it tries to do is access
priv->mfunc.vhcr, but that hasn't been allocated yet.
Fix this by moving the initialization of slave_sem and vhcr up into
mlx4_cmd_init(). Also, since slave_sem is really just being used as a
mutex, convert it into a slave_cmd_mutex.
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-09-26 12:24:07 +08:00
|
|
|
mutex_unlock(&priv->cmd.slave_cmd_mutex);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
mlx4_warn(dev, "Bad comm cmd:%d from slave:%d\n", cmd, slave);
|
|
|
|
goto reset_slave;
|
|
|
|
}
|
2012-11-28 00:24:30 +08:00
|
|
|
spin_lock_irqsave(&priv->mfunc.master.slave_state_lock, flags);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (!slave_state[slave].is_slave_going_down)
|
|
|
|
slave_state[slave].last_cmd = cmd;
|
|
|
|
else
|
|
|
|
is_going_down = 1;
|
2012-11-28 00:24:30 +08:00
|
|
|
spin_unlock_irqrestore(&priv->mfunc.master.slave_state_lock, flags);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (is_going_down) {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_warn(dev, "Slave is going down aborting command(%d) executing from slave:%d\n",
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
cmd, slave);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
__raw_writel((__force u32) cpu_to_be32(reply),
|
|
|
|
&priv->mfunc.comm[slave].slave_read);
|
|
|
|
mmiowb();
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
reset_slave:
|
mlx4_core: resource tracking for HCA resources used by guests
The resource tracker is used to track usage of HCA resources by the different
guests.
Virtual functions (VFs) are attached to guest operating systems but
resources are allocated from the same pool and are assigned to VFs. It is
essential that hostile/buggy guests not be able to affect the operation of
other VFs, possibly attached to other guest OSs since ConnectX firmware is not
tolerant to misuse of resources.
The resource tracker module associates each resource with a VF and maintains
state information for the allocated object. It also defines allowed state
transitions and enforces them.
Relationships between resources are also referred to. For example, CQs are
pointed to by QPs, so it is forbidden to destroy a CQ if a QP refers to it.
ICM memory is always accessible through the primary function and hence it is
allocated by the owner of the primary function.
When a guest dies, an FLR is generated for all the VFs it owns and all the
resources it used are freed.
The tracked resource types are: QPs, CQs, SRQs, MPTs, MTTs, MACs, RES_EQs,
and XRCDNs.
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:15:24 +08:00
|
|
|
/* cleanup any slave resources */
|
2015-01-25 22:59:42 +08:00
|
|
|
if (dev->persist->interface_state & MLX4_INTERFACE_STATE_UP)
|
|
|
|
mlx4_delete_all_resources_for_slave(dev, slave);
|
|
|
|
|
|
|
|
if (cmd != MLX4_COMM_CMD_RESET) {
|
|
|
|
mlx4_warn(dev, "Turn on internal error to force reset, slave=%d, cmd=0x%x\n",
|
|
|
|
slave, cmd);
|
|
|
|
/* Turn on internal error letting slave reset itself immeditaly,
|
|
|
|
* otherwise it might take till timeout on command is passed
|
|
|
|
*/
|
|
|
|
reply |= ((u32)COMM_CHAN_EVENT_INTERNAL_ERR);
|
|
|
|
}
|
|
|
|
|
2012-11-28 00:24:30 +08:00
|
|
|
spin_lock_irqsave(&priv->mfunc.master.slave_state_lock, flags);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (!slave_state[slave].is_slave_going_down)
|
|
|
|
slave_state[slave].last_cmd = MLX4_COMM_CMD_RESET;
|
2012-11-28 00:24:30 +08:00
|
|
|
spin_unlock_irqrestore(&priv->mfunc.master.slave_state_lock, flags);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
/*with slave in the middle of flr, no need to clean resources again.*/
|
|
|
|
inform_slave_state:
|
|
|
|
memset(&slave_state[slave].event_eq, 0,
|
|
|
|
sizeof(struct mlx4_slave_event_eq_info));
|
|
|
|
__raw_writel((__force u32) cpu_to_be32(reply),
|
|
|
|
&priv->mfunc.comm[slave].slave_read);
|
|
|
|
wmb();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* master command processing */
|
|
|
|
void mlx4_master_comm_channel(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct mlx4_mfunc_master_ctx *master =
|
|
|
|
container_of(work,
|
|
|
|
struct mlx4_mfunc_master_ctx,
|
|
|
|
comm_work);
|
|
|
|
struct mlx4_mfunc *mfunc =
|
|
|
|
container_of(master, struct mlx4_mfunc, master);
|
|
|
|
struct mlx4_priv *priv =
|
|
|
|
container_of(mfunc, struct mlx4_priv, mfunc);
|
|
|
|
struct mlx4_dev *dev = &priv->dev;
|
|
|
|
__be32 *bit_vec;
|
|
|
|
u32 comm_cmd;
|
|
|
|
u32 vec;
|
|
|
|
int i, j, slave;
|
|
|
|
int toggle;
|
|
|
|
int served = 0;
|
|
|
|
int reported = 0;
|
|
|
|
u32 slt;
|
|
|
|
|
|
|
|
bit_vec = master->comm_arm_bit_vector;
|
|
|
|
for (i = 0; i < COMM_CHANNEL_BIT_ARRAY_SIZE; i++) {
|
|
|
|
vec = be32_to_cpu(bit_vec[i]);
|
|
|
|
for (j = 0; j < 32; j++) {
|
|
|
|
if (!(vec & (1 << j)))
|
|
|
|
continue;
|
|
|
|
++reported;
|
|
|
|
slave = (i * 32) + j;
|
|
|
|
comm_cmd = swab32(readl(
|
|
|
|
&mfunc->comm[slave].slave_write));
|
|
|
|
slt = swab32(readl(&mfunc->comm[slave].slave_read))
|
|
|
|
>> 31;
|
|
|
|
toggle = comm_cmd >> 31;
|
|
|
|
if (toggle != slt) {
|
|
|
|
if (master->slave_state[slave].comm_toggle
|
|
|
|
!= slt) {
|
2014-05-22 20:55:40 +08:00
|
|
|
pr_info("slave %d out of sync. read toggle %d, state toggle %d. Resynching.\n",
|
|
|
|
slave, slt,
|
|
|
|
master->slave_state[slave].comm_toggle);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
master->slave_state[slave].comm_toggle =
|
|
|
|
slt;
|
|
|
|
}
|
|
|
|
mlx4_master_do_cmd(dev, slave,
|
|
|
|
comm_cmd >> 16 & 0xff,
|
|
|
|
comm_cmd & 0xffff, toggle);
|
|
|
|
++served;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (reported && reported != served)
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_warn(dev, "Got command event with bitmask from %d slaves but %d were served\n",
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
reported, served);
|
|
|
|
|
|
|
|
if (mlx4_ARM_COMM_CHANNEL(dev))
|
|
|
|
mlx4_warn(dev, "Failed to arm comm channel events\n");
|
|
|
|
}
|
|
|
|
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
static int sync_toggles(struct mlx4_dev *dev)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
2015-01-25 22:59:42 +08:00
|
|
|
u32 wr_toggle;
|
|
|
|
u32 rd_toggle;
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
unsigned long end;
|
|
|
|
|
2015-01-25 22:59:42 +08:00
|
|
|
wr_toggle = swab32(readl(&priv->mfunc.comm->slave_write));
|
|
|
|
if (wr_toggle == 0xffffffff)
|
|
|
|
end = jiffies + msecs_to_jiffies(30000);
|
|
|
|
else
|
|
|
|
end = jiffies + msecs_to_jiffies(5000);
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
|
|
|
|
while (time_before(jiffies, end)) {
|
2015-01-25 22:59:42 +08:00
|
|
|
rd_toggle = swab32(readl(&priv->mfunc.comm->slave_read));
|
|
|
|
if (wr_toggle == 0xffffffff || rd_toggle == 0xffffffff) {
|
|
|
|
/* PCI might be offline */
|
|
|
|
msleep(100);
|
|
|
|
wr_toggle = swab32(readl(&priv->mfunc.comm->
|
|
|
|
slave_write));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rd_toggle >> 31 == wr_toggle >> 31) {
|
|
|
|
priv->cmd.comm_toggle = rd_toggle >> 31;
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
cond_resched();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* we could reach here if for example the previous VM using this
|
|
|
|
* function misbehaved and left the channel with unsynced state. We
|
|
|
|
* should fix this here and give this VM a chance to use a properly
|
|
|
|
* synced channel
|
|
|
|
*/
|
|
|
|
mlx4_warn(dev, "recovering from previously mis-behaved VM\n");
|
|
|
|
__raw_writel((__force u32) 0, &priv->mfunc.comm->slave_read);
|
|
|
|
__raw_writel((__force u32) 0, &priv->mfunc.comm->slave_write);
|
|
|
|
priv->cmd.comm_toggle = 0;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int mlx4_multi_func_init(struct mlx4_dev *dev)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct mlx4_slave_state *s_state;
|
2012-01-19 17:45:46 +08:00
|
|
|
int i, j, err, port;
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
|
|
|
|
if (mlx4_is_master(dev))
|
|
|
|
priv->mfunc.comm =
|
2015-01-25 22:59:35 +08:00
|
|
|
ioremap(pci_resource_start(dev->persist->pdev,
|
|
|
|
priv->fw.comm_bar) +
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
priv->fw.comm_base, MLX4_COMM_PAGESIZE);
|
|
|
|
else
|
|
|
|
priv->mfunc.comm =
|
2015-01-25 22:59:35 +08:00
|
|
|
ioremap(pci_resource_start(dev->persist->pdev, 2) +
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
MLX4_SLAVE_COMM_BASE, MLX4_COMM_PAGESIZE);
|
|
|
|
if (!priv->mfunc.comm) {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_err(dev, "Couldn't map communication vector\n");
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
goto err_vhcr;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (mlx4_is_master(dev)) {
|
|
|
|
priv->mfunc.master.slave_state =
|
|
|
|
kzalloc(dev->num_slaves *
|
|
|
|
sizeof(struct mlx4_slave_state), GFP_KERNEL);
|
|
|
|
if (!priv->mfunc.master.slave_state)
|
|
|
|
goto err_comm;
|
|
|
|
|
2013-04-25 13:22:26 +08:00
|
|
|
priv->mfunc.master.vf_admin =
|
|
|
|
kzalloc(dev->num_slaves *
|
|
|
|
sizeof(struct mlx4_vf_admin_state), GFP_KERNEL);
|
|
|
|
if (!priv->mfunc.master.vf_admin)
|
|
|
|
goto err_comm_admin;
|
|
|
|
|
|
|
|
priv->mfunc.master.vf_oper =
|
|
|
|
kzalloc(dev->num_slaves *
|
|
|
|
sizeof(struct mlx4_vf_oper_state), GFP_KERNEL);
|
|
|
|
if (!priv->mfunc.master.vf_oper)
|
|
|
|
goto err_comm_oper;
|
|
|
|
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
for (i = 0; i < dev->num_slaves; ++i) {
|
|
|
|
s_state = &priv->mfunc.master.slave_state[i];
|
|
|
|
s_state->last_cmd = MLX4_COMM_CMD_RESET;
|
2012-01-19 17:45:46 +08:00
|
|
|
for (j = 0; j < MLX4_EVENT_TYPES_NUM; ++j)
|
|
|
|
s_state->event_eq[j].eqn = -1;
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
__raw_writel((__force u32) 0,
|
|
|
|
&priv->mfunc.comm[i].slave_write);
|
|
|
|
__raw_writel((__force u32) 0,
|
|
|
|
&priv->mfunc.comm[i].slave_read);
|
|
|
|
mmiowb();
|
|
|
|
for (port = 1; port <= MLX4_MAX_PORTS; port++) {
|
|
|
|
s_state->vlan_filter[port] =
|
|
|
|
kzalloc(sizeof(struct mlx4_vlan_fltr),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!s_state->vlan_filter[port]) {
|
|
|
|
if (--port)
|
|
|
|
kfree(s_state->vlan_filter[port]);
|
|
|
|
goto err_slaves;
|
|
|
|
}
|
|
|
|
INIT_LIST_HEAD(&s_state->mcast_filters[port]);
|
2013-04-25 13:22:26 +08:00
|
|
|
priv->mfunc.master.vf_admin[i].vport[port].default_vlan = MLX4_VGT;
|
2013-04-25 13:22:28 +08:00
|
|
|
priv->mfunc.master.vf_oper[i].vport[port].state.default_vlan = MLX4_VGT;
|
2013-04-25 13:22:26 +08:00
|
|
|
priv->mfunc.master.vf_oper[i].vport[port].vlan_idx = NO_INDX;
|
|
|
|
priv->mfunc.master.vf_oper[i].vport[port].mac_idx = NO_INDX;
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
}
|
|
|
|
spin_lock_init(&s_state->lock);
|
|
|
|
}
|
|
|
|
|
2012-10-21 22:59:24 +08:00
|
|
|
memset(&priv->mfunc.master.cmd_eqe, 0, dev->caps.eqe_size);
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
priv->mfunc.master.cmd_eqe.type = MLX4_EVENT_TYPE_CMD;
|
|
|
|
INIT_WORK(&priv->mfunc.master.comm_work,
|
|
|
|
mlx4_master_comm_channel);
|
|
|
|
INIT_WORK(&priv->mfunc.master.slave_event_work,
|
|
|
|
mlx4_gen_slave_eqe);
|
|
|
|
INIT_WORK(&priv->mfunc.master.slave_flr_event_work,
|
|
|
|
mlx4_master_handle_slave_flr);
|
|
|
|
spin_lock_init(&priv->mfunc.master.slave_state_lock);
|
2012-08-03 16:40:54 +08:00
|
|
|
spin_lock_init(&priv->mfunc.master.slave_eq.event_lock);
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
priv->mfunc.master.comm_wq =
|
|
|
|
create_singlethread_workqueue("mlx4_comm");
|
|
|
|
if (!priv->mfunc.master.comm_wq)
|
|
|
|
goto err_slaves;
|
|
|
|
|
|
|
|
if (mlx4_init_resource_tracker(dev))
|
|
|
|
goto err_thread;
|
|
|
|
|
|
|
|
} else {
|
|
|
|
err = sync_toggles(dev);
|
|
|
|
if (err) {
|
|
|
|
mlx4_err(dev, "Couldn't sync toggles\n");
|
|
|
|
goto err_comm;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_thread:
|
|
|
|
flush_workqueue(priv->mfunc.master.comm_wq);
|
|
|
|
destroy_workqueue(priv->mfunc.master.comm_wq);
|
|
|
|
err_slaves:
|
|
|
|
while (--i) {
|
|
|
|
for (port = 1; port <= MLX4_MAX_PORTS; port++)
|
|
|
|
kfree(priv->mfunc.master.slave_state[i].vlan_filter[port]);
|
|
|
|
}
|
2013-04-25 13:22:26 +08:00
|
|
|
kfree(priv->mfunc.master.vf_oper);
|
|
|
|
err_comm_oper:
|
|
|
|
kfree(priv->mfunc.master.vf_admin);
|
|
|
|
err_comm_admin:
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
kfree(priv->mfunc.master.slave_state);
|
|
|
|
err_comm:
|
|
|
|
iounmap(priv->mfunc.comm);
|
|
|
|
err_vhcr:
|
2015-01-25 22:59:35 +08:00
|
|
|
dma_free_coherent(&dev->persist->pdev->dev, PAGE_SIZE,
|
|
|
|
priv->mfunc.vhcr,
|
|
|
|
priv->mfunc.vhcr_dma);
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
priv->mfunc.vhcr = NULL;
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
int mlx4_cmd_init(struct mlx4_dev *dev)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
2014-11-13 20:45:29 +08:00
|
|
|
int flags = 0;
|
|
|
|
|
|
|
|
if (!priv->cmd.initialized) {
|
|
|
|
mutex_init(&priv->cmd.slave_cmd_mutex);
|
|
|
|
sema_init(&priv->cmd.poll_sem, 1);
|
|
|
|
priv->cmd.use_events = 0;
|
|
|
|
priv->cmd.toggle = 1;
|
|
|
|
priv->cmd.initialized = 1;
|
|
|
|
flags |= MLX4_CMD_CLEANUP_STRUCT;
|
|
|
|
}
|
2007-05-09 09:00:38 +08:00
|
|
|
|
2014-11-13 20:45:29 +08:00
|
|
|
if (!mlx4_is_slave(dev) && !priv->cmd.hcr) {
|
2015-01-25 22:59:35 +08:00
|
|
|
priv->cmd.hcr = ioremap(pci_resource_start(dev->persist->pdev,
|
|
|
|
0) + MLX4_HCR_BASE, MLX4_HCR_SIZE);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
if (!priv->cmd.hcr) {
|
2014-05-08 03:52:57 +08:00
|
|
|
mlx4_err(dev, "Couldn't map command register\n");
|
2014-11-13 20:45:29 +08:00
|
|
|
goto err;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
}
|
2014-11-13 20:45:29 +08:00
|
|
|
flags |= MLX4_CMD_CLEANUP_HCR;
|
2007-05-09 09:00:38 +08:00
|
|
|
}
|
|
|
|
|
2014-11-13 20:45:29 +08:00
|
|
|
if (mlx4_is_mfunc(dev) && !priv->mfunc.vhcr) {
|
2015-01-25 22:59:35 +08:00
|
|
|
priv->mfunc.vhcr = dma_alloc_coherent(&dev->persist->pdev->dev,
|
|
|
|
PAGE_SIZE,
|
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
before mlx4_multi_func_init(). However, for unlucky configurations,
mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
calls into mlx4_slave_cmd(), and that immediately tries to do
down(&priv->cmd.slave_sem);
but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
(which we haven't called yet). The next thing it tries to do is access
priv->mfunc.vhcr, but that hasn't been allocated yet.
Fix this by moving the initialization of slave_sem and vhcr up into
mlx4_cmd_init(). Also, since slave_sem is really just being used as a
mutex, convert it into a slave_cmd_mutex.
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-09-26 12:24:07 +08:00
|
|
|
&priv->mfunc.vhcr_dma,
|
|
|
|
GFP_KERNEL);
|
2013-03-14 21:07:21 +08:00
|
|
|
if (!priv->mfunc.vhcr)
|
2014-11-13 20:45:29 +08:00
|
|
|
goto err;
|
|
|
|
|
|
|
|
flags |= MLX4_CMD_CLEANUP_VHCR;
|
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
before mlx4_multi_func_init(). However, for unlucky configurations,
mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
calls into mlx4_slave_cmd(), and that immediately tries to do
down(&priv->cmd.slave_sem);
but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
(which we haven't called yet). The next thing it tries to do is access
priv->mfunc.vhcr, but that hasn't been allocated yet.
Fix this by moving the initialization of slave_sem and vhcr up into
mlx4_cmd_init(). Also, since slave_sem is really just being used as a
mutex, convert it into a slave_cmd_mutex.
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-09-26 12:24:07 +08:00
|
|
|
}
|
|
|
|
|
2014-11-13 20:45:29 +08:00
|
|
|
if (!priv->cmd.pool) {
|
2015-01-25 22:59:35 +08:00
|
|
|
priv->cmd.pool = pci_pool_create("mlx4_cmd",
|
|
|
|
dev->persist->pdev,
|
2014-11-13 20:45:29 +08:00
|
|
|
MLX4_MAILBOX_SIZE,
|
|
|
|
MLX4_MAILBOX_SIZE, 0);
|
|
|
|
if (!priv->cmd.pool)
|
|
|
|
goto err;
|
2007-05-09 09:00:38 +08:00
|
|
|
|
2014-11-13 20:45:29 +08:00
|
|
|
flags |= MLX4_CMD_CLEANUP_POOL;
|
|
|
|
}
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
|
2014-11-13 20:45:29 +08:00
|
|
|
return 0;
|
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
before mlx4_multi_func_init(). However, for unlucky configurations,
mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
calls into mlx4_slave_cmd(), and that immediately tries to do
down(&priv->cmd.slave_sem);
but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
(which we haven't called yet). The next thing it tries to do is access
priv->mfunc.vhcr, but that hasn't been allocated yet.
Fix this by moving the initialization of slave_sem and vhcr up into
mlx4_cmd_init(). Also, since slave_sem is really just being used as a
mutex, convert it into a slave_cmd_mutex.
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-09-26 12:24:07 +08:00
|
|
|
|
2014-11-13 20:45:29 +08:00
|
|
|
err:
|
|
|
|
mlx4_cmd_cleanup(dev, flags);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
return -ENOMEM;
|
2007-05-09 09:00:38 +08:00
|
|
|
}
|
|
|
|
|
2015-01-25 22:59:42 +08:00
|
|
|
void mlx4_report_internal_err_comm_event(struct mlx4_dev *dev)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
int slave;
|
|
|
|
u32 slave_read;
|
|
|
|
|
|
|
|
/* Report an internal error event to all
|
|
|
|
* communication channels.
|
|
|
|
*/
|
|
|
|
for (slave = 0; slave < dev->num_slaves; slave++) {
|
|
|
|
slave_read = swab32(readl(&priv->mfunc.comm[slave].slave_read));
|
|
|
|
slave_read |= (u32)COMM_CHAN_EVENT_INTERNAL_ERR;
|
|
|
|
__raw_writel((__force u32)cpu_to_be32(slave_read),
|
|
|
|
&priv->mfunc.comm[slave].slave_read);
|
|
|
|
/* Make sure that our comm channel write doesn't
|
|
|
|
* get mixed in with writes from another CPU.
|
|
|
|
*/
|
|
|
|
mmiowb();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
void mlx4_multi_func_cleanup(struct mlx4_dev *dev)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
int i, port;
|
|
|
|
|
|
|
|
if (mlx4_is_master(dev)) {
|
|
|
|
flush_workqueue(priv->mfunc.master.comm_wq);
|
|
|
|
destroy_workqueue(priv->mfunc.master.comm_wq);
|
|
|
|
for (i = 0; i < dev->num_slaves; i++) {
|
|
|
|
for (port = 1; port <= MLX4_MAX_PORTS; port++)
|
|
|
|
kfree(priv->mfunc.master.slave_state[i].vlan_filter[port]);
|
|
|
|
}
|
|
|
|
kfree(priv->mfunc.master.slave_state);
|
2013-04-25 13:22:26 +08:00
|
|
|
kfree(priv->mfunc.master.vf_admin);
|
|
|
|
kfree(priv->mfunc.master.vf_oper);
|
2015-01-25 22:59:42 +08:00
|
|
|
dev->num_slaves = 0;
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
}
|
2012-02-06 14:26:17 +08:00
|
|
|
|
|
|
|
iounmap(priv->mfunc.comm);
|
mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet
1. Added module parameters sr_iov and probe_vf for controlling enablement of
SRIOV mode.
2. Increased default max num-qps, num-mpts and log_num_macs to accomodate
SRIOV mode
3. Added port_type_array as a module parameter to allow driver startup with
ports configured as desired.
In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
for the case where the FW supports both port types (ETH and IB), the
port_type_array parameter is used.
By default, the port_type_array is set to configure both ports as IB.
4. When running in sriov mode, the master needs to initialize the ICM eq table
to hold the eq's for itself and also for all the slaves.
5. mlx4_set_port_mask() now invoked from mlx4_init_hca, instead of in mlx4_dev_cap.
6. Introduced sriov VF (slave) device startup/teardown logic (mainly procedures
mlx4_init_slave, mlx4_slave_exit, mlx4_slave_cap, mlx4_slave_exit and flow
modifications in __mlx4_init_one, mlx4_init_hca, and mlx4_setup_hca).
VFs obtain their startup information from the PF (master) device via the
comm channel.
7. In SRIOV mode (both PF and VF), MSI_X must be enabled, or the driver
aborts loading the device.
8. Do not allow setting port type via sysfs when running in SRIOV mode.
9. mlx4_get_ownership: Currently, only one PF is supported by the driver.
If the HCA is burned with FW which enables more than one PF, only one
of the PFs is allowed to run. The first one up grabs a FW ownership
semaphone -- all other PFs will find that semaphore taken, and the
driver will not allow them to run.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: Liran Liss <liranl@mellanox.co.il>
Signed-off-by: Marcel Apfelbaum <marcela@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:18:30 +08:00
|
|
|
}
|
|
|
|
|
2014-11-13 20:45:29 +08:00
|
|
|
void mlx4_cmd_cleanup(struct mlx4_dev *dev, int cleanup_mask)
|
2007-05-09 09:00:38 +08:00
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
|
2014-11-13 20:45:29 +08:00
|
|
|
if (priv->cmd.pool && (cleanup_mask & MLX4_CMD_CLEANUP_POOL)) {
|
|
|
|
pci_pool_destroy(priv->cmd.pool);
|
|
|
|
priv->cmd.pool = NULL;
|
|
|
|
}
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
|
2014-11-13 20:45:29 +08:00
|
|
|
if (!mlx4_is_slave(dev) && priv->cmd.hcr &&
|
|
|
|
(cleanup_mask & MLX4_CMD_CLEANUP_HCR)) {
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
iounmap(priv->cmd.hcr);
|
2014-11-13 20:45:29 +08:00
|
|
|
priv->cmd.hcr = NULL;
|
|
|
|
}
|
|
|
|
if (mlx4_is_mfunc(dev) && priv->mfunc.vhcr &&
|
|
|
|
(cleanup_mask & MLX4_CMD_CLEANUP_VHCR)) {
|
2015-01-25 22:59:35 +08:00
|
|
|
dma_free_coherent(&dev->persist->pdev->dev, PAGE_SIZE,
|
mlx4_core: Fix crash on uninitialized priv->cmd.slave_sem
On an SR-IOV master device, __mlx4_init_one() calls mlx4_init_hca()
before mlx4_multi_func_init(). However, for unlucky configurations,
mlx4_init_hca() might call mlx4_SENSE_PORT() (via mlx4_dev_cap()), and
that calls mlx4_cmd_imm() with MLX4_CMD_WRAPPED set.
However, on a multifunction device with MLX4_CMD_WRAPPED, __mlx4_cmd()
calls into mlx4_slave_cmd(), and that immediately tries to do
down(&priv->cmd.slave_sem);
but priv->cmd.slave_sem isn't initialized until mlx4_multi_func_init()
(which we haven't called yet). The next thing it tries to do is access
priv->mfunc.vhcr, but that hasn't been allocated yet.
Fix this by moving the initialization of slave_sem and vhcr up into
mlx4_cmd_init(). Also, since slave_sem is really just being used as a
mutex, convert it into a slave_cmd_mutex.
Signed-off-by: Roland Dreier <roland@purestorage.com>
2012-09-26 12:24:07 +08:00
|
|
|
priv->mfunc.vhcr, priv->mfunc.vhcr_dma);
|
2014-11-13 20:45:29 +08:00
|
|
|
priv->mfunc.vhcr = NULL;
|
|
|
|
}
|
|
|
|
if (priv->cmd.initialized && (cleanup_mask & MLX4_CMD_CLEANUP_STRUCT))
|
|
|
|
priv->cmd.initialized = 0;
|
2007-05-09 09:00:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Switch to using events to issue FW commands (can only be called
|
|
|
|
* after event queue for command events has been initialized).
|
|
|
|
*/
|
|
|
|
int mlx4_cmd_use_events(struct mlx4_dev *dev)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
int i;
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
int err = 0;
|
2007-05-09 09:00:38 +08:00
|
|
|
|
|
|
|
priv->cmd.context = kmalloc(priv->cmd.max_cmds *
|
|
|
|
sizeof (struct mlx4_cmd_context),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!priv->cmd.context)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
for (i = 0; i < priv->cmd.max_cmds; ++i) {
|
|
|
|
priv->cmd.context[i].token = i;
|
|
|
|
priv->cmd.context[i].next = i + 1;
|
2015-01-25 22:59:39 +08:00
|
|
|
/* To support fatal error flow, initialize all
|
|
|
|
* cmd contexts to allow simulating completions
|
|
|
|
* with complete() at any time.
|
|
|
|
*/
|
|
|
|
init_completion(&priv->cmd.context[i].done);
|
2007-05-09 09:00:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
priv->cmd.context[priv->cmd.max_cmds - 1].next = -1;
|
|
|
|
priv->cmd.free_head = 0;
|
|
|
|
|
|
|
|
sema_init(&priv->cmd.event_sem, priv->cmd.max_cmds);
|
|
|
|
spin_lock_init(&priv->cmd.context_lock);
|
|
|
|
|
|
|
|
for (priv->cmd.token_mask = 1;
|
|
|
|
priv->cmd.token_mask < priv->cmd.max_cmds;
|
|
|
|
priv->cmd.token_mask <<= 1)
|
|
|
|
; /* nothing */
|
|
|
|
--priv->cmd.token_mask;
|
|
|
|
|
|
|
|
down(&priv->cmd.poll_sem);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
priv->cmd.use_events = 1;
|
2007-05-09 09:00:38 +08:00
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
return err;
|
2007-05-09 09:00:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Switch back to polling (used when shutting down the device)
|
|
|
|
*/
|
|
|
|
void mlx4_cmd_use_polling(struct mlx4_dev *dev)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
priv->cmd.use_events = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < priv->cmd.max_cmds; ++i)
|
|
|
|
down(&priv->cmd.event_sem);
|
|
|
|
|
|
|
|
kfree(priv->cmd.context);
|
|
|
|
|
|
|
|
up(&priv->cmd.poll_sem);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct mlx4_cmd_mailbox *mlx4_alloc_cmd_mailbox(struct mlx4_dev *dev)
|
|
|
|
{
|
|
|
|
struct mlx4_cmd_mailbox *mailbox;
|
|
|
|
|
|
|
|
mailbox = kmalloc(sizeof *mailbox, GFP_KERNEL);
|
|
|
|
if (!mailbox)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
mailbox->buf = pci_pool_alloc(mlx4_priv(dev)->cmd.pool, GFP_KERNEL,
|
|
|
|
&mailbox->dma);
|
|
|
|
if (!mailbox->buf) {
|
|
|
|
kfree(mailbox);
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
}
|
|
|
|
|
2013-11-07 18:19:50 +08:00
|
|
|
memset(mailbox->buf, 0, MLX4_MAILBOX_SIZE);
|
|
|
|
|
2007-05-09 09:00:38 +08:00
|
|
|
return mailbox;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_alloc_cmd_mailbox);
|
|
|
|
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
void mlx4_free_cmd_mailbox(struct mlx4_dev *dev,
|
|
|
|
struct mlx4_cmd_mailbox *mailbox)
|
2007-05-09 09:00:38 +08:00
|
|
|
{
|
|
|
|
if (!mailbox)
|
|
|
|
return;
|
|
|
|
|
|
|
|
pci_pool_free(mlx4_priv(dev)->cmd.pool, mailbox->buf, mailbox->dma);
|
|
|
|
kfree(mailbox);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_free_cmd_mailbox);
|
net/mlx4_core: Implement the master-slave communication channel
When SRIOV is enabled, pf and vfs communicate via shared comm channel.
The vf gets its side of the comm channel via a VF BAR.
Each VF (slave) creates its vHCR (virtual HCA Command Register),
Its DMA address is passed to the PF (master) using Communication Channel Register.
The same Register is used to notify the master of commands posted by the
slaves and for the master to pass events to the slaves, such as command completions
and asynchronous events.
The vHCR format is identical to the HCR format, except for the 'go' and 't' bits,
which are reserved in the vHCR. Posting commands to the vHCR is identical to
the way it is done with the HCR, albeit that the function/PF token fields are
used instead of the HCR go bit.
Specifically:
- When the function prepares a new command in the vHCR, it issues the Post_vHCR_cmd
communication channel command and toggles the value of the function token;
when PF token has an equal value, the command has been accepted and a new command may be posted.
- When the PF detects a Post_vHCR_cmd command, it concludes that a new command is available in the vHCR;
after processing the command, the PF toggles the PF token to match the function token.
When the 'e' bit is not set, the completion of a Post_vHCR_cmd command also indicates
the completion the vHCR command. If, however, the 'e' bit is set, the completion of a
Post_vHCR_cmd command only indicates that the vHCR command has been accepted for execution by the PF.
Function commands are processed by the PF as follows:
-DMA (using the ACCESS_MEM command) the vHCR image into a shadow buffer.
-Validate that the opcode is non-privileged, and that the opcode- and input-modifiers are legal.
-DMA the in-box (if required) into a shadow buffer.
-Validate the command:
o Resource ranges (e.g., QP ranges).
o Partition key.
o Ranges of referenced resources (e.g., CQs within QP contexts).
-If the 'e' bit is set
o complete the Post_vHCR_cmd command
-Execute the command on the HCR.
-DMA the results to the vHCR out-box (if required).
-If the 'e' bit is set
o Indicate command completion by generating a completion event using the GEN_EQE command
-Otherwise
o DMA the command status to the vHCR
o Complete the Post_vHCR_cmd command
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Yevgeny Petrillin <yevgenyp@mellanox.com>
Signed-off-by: Liran Liss <liranl@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-12-13 12:12:25 +08:00
|
|
|
|
|
|
|
u32 mlx4_comm_get_version(void)
|
|
|
|
{
|
|
|
|
return ((u32) CMD_CHAN_IF_REV << 8) | (u32) CMD_CHAN_VER;
|
|
|
|
}
|
2013-04-25 13:22:27 +08:00
|
|
|
|
|
|
|
static int mlx4_get_slave_indx(struct mlx4_dev *dev, int vf)
|
|
|
|
{
|
2015-01-25 22:59:35 +08:00
|
|
|
if ((vf < 0) || (vf >= dev->persist->num_vfs)) {
|
|
|
|
mlx4_err(dev, "Bad vf number:%d (number of activated vf: %d)\n",
|
|
|
|
vf, dev->persist->num_vfs);
|
2013-04-25 13:22:27 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return vf+1;
|
|
|
|
}
|
|
|
|
|
2014-03-20 00:11:51 +08:00
|
|
|
int mlx4_get_vf_indx(struct mlx4_dev *dev, int slave)
|
|
|
|
{
|
2015-01-25 22:59:35 +08:00
|
|
|
if (slave < 1 || slave > dev->persist->num_vfs) {
|
2014-03-20 00:11:51 +08:00
|
|
|
mlx4_err(dev,
|
|
|
|
"Bad slave number:%d (number of activated slaves: %lu)\n",
|
|
|
|
slave, dev->num_slaves);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
return slave - 1;
|
|
|
|
}
|
|
|
|
|
2015-01-25 22:59:39 +08:00
|
|
|
void mlx4_cmd_wake_completions(struct mlx4_dev *dev)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct mlx4_cmd_context *context;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
spin_lock(&priv->cmd.context_lock);
|
|
|
|
if (priv->cmd.context) {
|
|
|
|
for (i = 0; i < priv->cmd.max_cmds; ++i) {
|
|
|
|
context = &priv->cmd.context[i];
|
|
|
|
context->fw_status = CMD_STAT_INTERNAL_ERR;
|
|
|
|
context->result =
|
|
|
|
mlx4_status_to_errno(CMD_STAT_INTERNAL_ERR);
|
|
|
|
complete(&context->done);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
spin_unlock(&priv->cmd.context_lock);
|
|
|
|
}
|
|
|
|
|
2014-03-20 00:11:51 +08:00
|
|
|
struct mlx4_active_ports mlx4_get_active_ports(struct mlx4_dev *dev, int slave)
|
|
|
|
{
|
|
|
|
struct mlx4_active_ports actv_ports;
|
|
|
|
int vf;
|
|
|
|
|
|
|
|
bitmap_zero(actv_ports.ports, MLX4_MAX_PORTS);
|
|
|
|
|
|
|
|
if (slave == 0) {
|
|
|
|
bitmap_fill(actv_ports.ports, dev->caps.num_ports);
|
|
|
|
return actv_ports;
|
|
|
|
}
|
|
|
|
|
|
|
|
vf = mlx4_get_vf_indx(dev, slave);
|
|
|
|
if (vf < 0)
|
|
|
|
return actv_ports;
|
|
|
|
|
|
|
|
bitmap_set(actv_ports.ports, dev->dev_vfs[vf].min_port - 1,
|
|
|
|
min((int)dev->dev_vfs[mlx4_get_vf_indx(dev, slave)].n_ports,
|
|
|
|
dev->caps.num_ports));
|
|
|
|
|
|
|
|
return actv_ports;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_get_active_ports);
|
|
|
|
|
|
|
|
int mlx4_slave_convert_port(struct mlx4_dev *dev, int slave, int port)
|
|
|
|
{
|
|
|
|
unsigned n;
|
|
|
|
struct mlx4_active_ports actv_ports = mlx4_get_active_ports(dev, slave);
|
|
|
|
unsigned m = bitmap_weight(actv_ports.ports, dev->caps.num_ports);
|
|
|
|
|
|
|
|
if (port <= 0 || port > m)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
n = find_first_bit(actv_ports.ports, dev->caps.num_ports);
|
|
|
|
if (port <= n)
|
|
|
|
port = n + 1;
|
|
|
|
|
|
|
|
return port;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_slave_convert_port);
|
|
|
|
|
|
|
|
int mlx4_phys_to_slave_port(struct mlx4_dev *dev, int slave, int port)
|
|
|
|
{
|
|
|
|
struct mlx4_active_ports actv_ports = mlx4_get_active_ports(dev, slave);
|
|
|
|
if (test_bit(port - 1, actv_ports.ports))
|
|
|
|
return port -
|
|
|
|
find_first_bit(actv_ports.ports, dev->caps.num_ports);
|
|
|
|
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_phys_to_slave_port);
|
|
|
|
|
|
|
|
struct mlx4_slaves_pport mlx4_phys_to_slaves_pport(struct mlx4_dev *dev,
|
|
|
|
int port)
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
struct mlx4_slaves_pport slaves_pport;
|
|
|
|
|
|
|
|
bitmap_zero(slaves_pport.slaves, MLX4_MFUNC_MAX);
|
|
|
|
|
|
|
|
if (port <= 0 || port > dev->caps.num_ports)
|
|
|
|
return slaves_pport;
|
|
|
|
|
2015-01-25 22:59:35 +08:00
|
|
|
for (i = 0; i < dev->persist->num_vfs + 1; i++) {
|
2014-03-20 00:11:51 +08:00
|
|
|
struct mlx4_active_ports actv_ports =
|
|
|
|
mlx4_get_active_ports(dev, i);
|
|
|
|
if (test_bit(port - 1, actv_ports.ports))
|
|
|
|
set_bit(i, slaves_pport.slaves);
|
|
|
|
}
|
|
|
|
|
|
|
|
return slaves_pport;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_phys_to_slaves_pport);
|
|
|
|
|
|
|
|
struct mlx4_slaves_pport mlx4_phys_to_slaves_pport_actv(
|
|
|
|
struct mlx4_dev *dev,
|
|
|
|
const struct mlx4_active_ports *crit_ports)
|
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
struct mlx4_slaves_pport slaves_pport;
|
|
|
|
|
|
|
|
bitmap_zero(slaves_pport.slaves, MLX4_MFUNC_MAX);
|
|
|
|
|
2015-01-25 22:59:35 +08:00
|
|
|
for (i = 0; i < dev->persist->num_vfs + 1; i++) {
|
2014-03-20 00:11:51 +08:00
|
|
|
struct mlx4_active_ports actv_ports =
|
|
|
|
mlx4_get_active_ports(dev, i);
|
|
|
|
if (bitmap_equal(crit_ports->ports, actv_ports.ports,
|
|
|
|
dev->caps.num_ports))
|
|
|
|
set_bit(i, slaves_pport.slaves);
|
|
|
|
}
|
|
|
|
|
|
|
|
return slaves_pport;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_phys_to_slaves_pport_actv);
|
|
|
|
|
2014-09-10 21:41:53 +08:00
|
|
|
static int mlx4_slaves_closest_port(struct mlx4_dev *dev, int slave, int port)
|
|
|
|
{
|
|
|
|
struct mlx4_active_ports actv_ports = mlx4_get_active_ports(dev, slave);
|
|
|
|
int min_port = find_first_bit(actv_ports.ports, dev->caps.num_ports)
|
|
|
|
+ 1;
|
|
|
|
int max_port = min_port +
|
|
|
|
bitmap_weight(actv_ports.ports, dev->caps.num_ports);
|
|
|
|
|
|
|
|
if (port < min_port)
|
|
|
|
port = min_port;
|
|
|
|
else if (port >= max_port)
|
|
|
|
port = max_port - 1;
|
|
|
|
|
|
|
|
return port;
|
|
|
|
}
|
|
|
|
|
2013-04-25 13:22:27 +08:00
|
|
|
int mlx4_set_vf_mac(struct mlx4_dev *dev, int port, int vf, u64 mac)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct mlx4_vport_state *s_info;
|
|
|
|
int slave;
|
|
|
|
|
|
|
|
if (!mlx4_is_master(dev))
|
|
|
|
return -EPROTONOSUPPORT;
|
|
|
|
|
|
|
|
slave = mlx4_get_slave_indx(dev, vf);
|
|
|
|
if (slave < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-10 21:41:53 +08:00
|
|
|
port = mlx4_slaves_closest_port(dev, slave, port);
|
2013-04-25 13:22:27 +08:00
|
|
|
s_info = &priv->mfunc.master.vf_admin[slave].vport[port];
|
|
|
|
s_info->mac = mac;
|
|
|
|
mlx4_info(dev, "default mac on vf %d port %d to %llX will take afect only after vf restart\n",
|
|
|
|
vf, port, s_info->mac);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_set_vf_mac);
|
2013-04-25 13:22:28 +08:00
|
|
|
|
2013-06-28 00:05:21 +08:00
|
|
|
|
2013-04-25 13:22:28 +08:00
|
|
|
int mlx4_set_vf_vlan(struct mlx4_dev *dev, int port, int vf, u16 vlan, u8 qos)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
2013-06-28 00:05:21 +08:00
|
|
|
struct mlx4_vport_state *vf_admin;
|
2013-04-25 13:22:28 +08:00
|
|
|
int slave;
|
|
|
|
|
|
|
|
if ((!mlx4_is_master(dev)) ||
|
|
|
|
!(dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_VLAN_CONTROL))
|
|
|
|
return -EPROTONOSUPPORT;
|
|
|
|
|
|
|
|
if ((vlan > 4095) || (qos > 7))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
slave = mlx4_get_slave_indx(dev, vf);
|
|
|
|
if (slave < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-10 21:41:53 +08:00
|
|
|
port = mlx4_slaves_closest_port(dev, slave, port);
|
2013-06-28 00:05:21 +08:00
|
|
|
vf_admin = &priv->mfunc.master.vf_admin[slave].vport[port];
|
|
|
|
|
2013-04-25 13:22:28 +08:00
|
|
|
if ((0 == vlan) && (0 == qos))
|
2013-06-28 00:05:21 +08:00
|
|
|
vf_admin->default_vlan = MLX4_VGT;
|
2013-04-25 13:22:28 +08:00
|
|
|
else
|
2013-06-28 00:05:21 +08:00
|
|
|
vf_admin->default_vlan = vlan;
|
|
|
|
vf_admin->default_qos = qos;
|
|
|
|
|
2013-06-28 00:05:22 +08:00
|
|
|
if (mlx4_master_immediate_activate_vlan_qos(priv, slave, port))
|
|
|
|
mlx4_info(dev,
|
|
|
|
"updating vf %d port %d config will take effect on next VF restart\n",
|
2013-06-28 00:05:21 +08:00
|
|
|
vf, port);
|
2013-04-25 13:22:28 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_set_vf_vlan);
|
2013-04-25 13:22:29 +08:00
|
|
|
|
mlx4: Implement IP based gids support for RoCE/SRIOV
Since there is no connection between the MAC/VLAN and the GID
when using IP-based addressing, the proxy QP1 (running on the
slave) must pass the source-mac, destination-mac, and vlan_id
information separately from the GID. Additionally, the Host
must pass the remote source-mac and vlan_id back to the slave,
This is achieved as follows:
Outgoing MADs:
1. Source MAC: obtained from the CQ completion structure
(struct ib_wc, smac field).
2. Destination MAC: obtained from the tunnel header
3. vlan_id: obtained from the tunnel header.
Incoming MADs
1. The source (i.e., remote) MAC and vlan_id are passed in
the tunnel header to the proxy QP1.
VST mode support:
For outgoing MADs, the vlan_id obtained from the header is
discarded, and the vlan_id specified by the Hypervisor is used
instead.
For incoming MADs, the incoming vlan_id (in the wc) is discarded, and the
"invalid" vlan (0xffff) is substituted when forwarding to the slave.
Signed-off-by: Moni Shoua <monis@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-12 18:00:41 +08:00
|
|
|
/* mlx4_get_slave_default_vlan -
|
|
|
|
* return true if VST ( default vlan)
|
|
|
|
* if VST, will return vlan & qos (if not NULL)
|
|
|
|
*/
|
|
|
|
bool mlx4_get_slave_default_vlan(struct mlx4_dev *dev, int port, int slave,
|
|
|
|
u16 *vlan, u8 *qos)
|
|
|
|
{
|
|
|
|
struct mlx4_vport_oper_state *vp_oper;
|
|
|
|
struct mlx4_priv *priv;
|
|
|
|
|
|
|
|
priv = mlx4_priv(dev);
|
2014-09-10 21:41:53 +08:00
|
|
|
port = mlx4_slaves_closest_port(dev, slave, port);
|
mlx4: Implement IP based gids support for RoCE/SRIOV
Since there is no connection between the MAC/VLAN and the GID
when using IP-based addressing, the proxy QP1 (running on the
slave) must pass the source-mac, destination-mac, and vlan_id
information separately from the GID. Additionally, the Host
must pass the remote source-mac and vlan_id back to the slave,
This is achieved as follows:
Outgoing MADs:
1. Source MAC: obtained from the CQ completion structure
(struct ib_wc, smac field).
2. Destination MAC: obtained from the tunnel header
3. vlan_id: obtained from the tunnel header.
Incoming MADs
1. The source (i.e., remote) MAC and vlan_id are passed in
the tunnel header to the proxy QP1.
VST mode support:
For outgoing MADs, the vlan_id obtained from the header is
discarded, and the vlan_id specified by the Hypervisor is used
instead.
For incoming MADs, the incoming vlan_id (in the wc) is discarded, and the
"invalid" vlan (0xffff) is substituted when forwarding to the slave.
Signed-off-by: Moni Shoua <monis@mellanox.co.il>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-12 18:00:41 +08:00
|
|
|
vp_oper = &priv->mfunc.master.vf_oper[slave].vport[port];
|
|
|
|
|
|
|
|
if (MLX4_VGT != vp_oper->state.default_vlan) {
|
|
|
|
if (vlan)
|
|
|
|
*vlan = vp_oper->state.default_vlan;
|
|
|
|
if (qos)
|
|
|
|
*qos = vp_oper->state.default_qos;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_get_slave_default_vlan);
|
|
|
|
|
2013-04-25 13:22:29 +08:00
|
|
|
int mlx4_set_vf_spoofchk(struct mlx4_dev *dev, int port, int vf, bool setting)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct mlx4_vport_state *s_info;
|
|
|
|
int slave;
|
|
|
|
|
|
|
|
if ((!mlx4_is_master(dev)) ||
|
|
|
|
!(dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_FSM))
|
|
|
|
return -EPROTONOSUPPORT;
|
|
|
|
|
|
|
|
slave = mlx4_get_slave_indx(dev, vf);
|
|
|
|
if (slave < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-10 21:41:53 +08:00
|
|
|
port = mlx4_slaves_closest_port(dev, slave, port);
|
2013-04-25 13:22:29 +08:00
|
|
|
s_info = &priv->mfunc.master.vf_admin[slave].vport[port];
|
|
|
|
s_info->spoofchk = setting;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_set_vf_spoofchk);
|
2013-04-25 13:22:30 +08:00
|
|
|
|
|
|
|
int mlx4_get_vf_config(struct mlx4_dev *dev, int port, int vf, struct ifla_vf_info *ivf)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct mlx4_vport_state *s_info;
|
|
|
|
int slave;
|
|
|
|
|
|
|
|
if (!mlx4_is_master(dev))
|
|
|
|
return -EPROTONOSUPPORT;
|
|
|
|
|
|
|
|
slave = mlx4_get_slave_indx(dev, vf);
|
|
|
|
if (slave < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
s_info = &priv->mfunc.master.vf_admin[slave].vport[port];
|
|
|
|
ivf->vf = vf;
|
|
|
|
|
|
|
|
/* need to convert it to a func */
|
|
|
|
ivf->mac[0] = ((s_info->mac >> (5*8)) & 0xff);
|
|
|
|
ivf->mac[1] = ((s_info->mac >> (4*8)) & 0xff);
|
|
|
|
ivf->mac[2] = ((s_info->mac >> (3*8)) & 0xff);
|
|
|
|
ivf->mac[3] = ((s_info->mac >> (2*8)) & 0xff);
|
|
|
|
ivf->mac[4] = ((s_info->mac >> (1*8)) & 0xff);
|
|
|
|
ivf->mac[5] = ((s_info->mac) & 0xff);
|
|
|
|
|
net-next:v4: Add support to configure SR-IOV VF minimum and maximum Tx rate through ip tool.
o min_tx_rate puts lower limit on the VF bandwidth. VF is guaranteed
to have a bandwidth of at least this value.
max_tx_rate puts cap on the VF bandwidth. VF can have a bandwidth
of up to this value.
o A new handler set_vf_rate for attr IFLA_VF_RATE has been introduced
which takes 4 arguments:
netdev, VF number, min_tx_rate, max_tx_rate
o ndo_set_vf_rate replaces ndo_set_vf_tx_rate handler.
o Drivers that currently implement ndo_set_vf_tx_rate should now call
ndo_set_vf_rate instead and reject attempt to set a minimum bandwidth
greater than 0 for IFLA_VF_TX_RATE when IFLA_VF_RATE is not yet
implemented by driver.
o If user enters only one of either min_tx_rate or max_tx_rate, then,
userland should read back the other value from driver and set both
for IFLA_VF_RATE.
Drivers that have not yet implemented IFLA_VF_RATE should always
return min_tx_rate as 0 when read from ip tool.
o If both IFLA_VF_TX_RATE and IFLA_VF_RATE options are specified, then
IFLA_VF_RATE should override.
o Idea is to have consistent display of rate values to user.
o Usage example: -
./ip link set p4p1 vf 0 rate 900
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 900 (Mbps), max_tx_rate 900Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
./ip link set p4p1 vf 0 max_tx_rate 300 min_tx_rate 200
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f0 brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5a, tx rate 300 (Mbps), max_tx_rate 300Mbps,
min_tx_rate 200Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
./ip link set p4p1 vf 0 max_tx_rate 600 rate 300
./ip link show p4p1
32: p4p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
DEFAULT qlen 1000
link/ether 00:0e:1e:08:b0:f brd ff:ff:ff:ff:ff:ff
vf 0 MAC 3e:a0:ca:bd:ae:5, tx rate 600 (Mbps), max_tx_rate 600Mbps,
min_tx_rate 200Mbps
vf 1 MAC f6:c6:7c:3f:3d:6c
vf 2 MAC 56:32:43:98:d7:71
vf 3 MAC d6:be:c3:b5:85:ff
vf 4 MAC ee:a9:9a:1e:19:14
vf 5 MAC 4a:d0:4c:07:52:18
vf 6 MAC 3a:76:44:93:62:f9
vf 7 MAC 82:e9:e7:e3:15:1a
Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-22 21:59:05 +08:00
|
|
|
ivf->vlan = s_info->default_vlan;
|
|
|
|
ivf->qos = s_info->default_qos;
|
|
|
|
ivf->max_tx_rate = s_info->tx_rate;
|
|
|
|
ivf->min_tx_rate = 0;
|
|
|
|
ivf->spoofchk = s_info->spoofchk;
|
|
|
|
ivf->linkstate = s_info->link_state;
|
2013-04-25 13:22:30 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_get_vf_config);
|
2013-06-13 18:19:11 +08:00
|
|
|
|
|
|
|
int mlx4_set_vf_link_state(struct mlx4_dev *dev, int port, int vf, int link_state)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
struct mlx4_vport_state *s_info;
|
|
|
|
int slave;
|
|
|
|
u8 link_stat_event;
|
|
|
|
|
|
|
|
slave = mlx4_get_slave_indx(dev, vf);
|
|
|
|
if (slave < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-09-10 21:41:53 +08:00
|
|
|
port = mlx4_slaves_closest_port(dev, slave, port);
|
2013-06-13 18:19:11 +08:00
|
|
|
switch (link_state) {
|
|
|
|
case IFLA_VF_LINK_STATE_AUTO:
|
|
|
|
/* get current link state */
|
|
|
|
if (!priv->sense.do_sense_port[port])
|
|
|
|
link_stat_event = MLX4_PORT_CHANGE_SUBTYPE_ACTIVE;
|
|
|
|
else
|
|
|
|
link_stat_event = MLX4_PORT_CHANGE_SUBTYPE_DOWN;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IFLA_VF_LINK_STATE_ENABLE:
|
|
|
|
link_stat_event = MLX4_PORT_CHANGE_SUBTYPE_ACTIVE;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case IFLA_VF_LINK_STATE_DISABLE:
|
|
|
|
link_stat_event = MLX4_PORT_CHANGE_SUBTYPE_DOWN;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
mlx4_warn(dev, "unknown value for link_state %02x on slave %d port %d\n",
|
|
|
|
link_state, slave, port);
|
|
|
|
return -EINVAL;
|
|
|
|
};
|
|
|
|
s_info = &priv->mfunc.master.vf_admin[slave].vport[port];
|
|
|
|
s_info->link_state = link_state;
|
|
|
|
|
|
|
|
/* send event */
|
|
|
|
mlx4_gen_port_state_change_eqe(dev, slave, port, link_stat_event);
|
2013-06-28 00:05:22 +08:00
|
|
|
|
|
|
|
if (mlx4_master_immediate_activate_vlan_qos(priv, slave, port))
|
|
|
|
mlx4_dbg(dev,
|
|
|
|
"updating vf %d port %d no link state HW enforcment\n",
|
|
|
|
vf, port);
|
2013-06-13 18:19:11 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_set_vf_link_state);
|
2014-05-29 21:31:02 +08:00
|
|
|
|
|
|
|
int mlx4_vf_smi_enabled(struct mlx4_dev *dev, int slave, int port)
|
|
|
|
{
|
2014-05-29 21:31:03 +08:00
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
|
|
|
|
if (slave < 1 || slave >= dev->num_slaves ||
|
|
|
|
port < 1 || port > MLX4_MAX_PORTS)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return priv->mfunc.master.vf_oper[slave].smi_enabled[port] ==
|
|
|
|
MLX4_VF_SMI_ENABLED;
|
2014-05-29 21:31:02 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_vf_smi_enabled);
|
2014-05-29 21:31:04 +08:00
|
|
|
|
|
|
|
int mlx4_vf_get_enable_smi_admin(struct mlx4_dev *dev, int slave, int port)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
|
|
|
|
if (slave == mlx4_master_func_num(dev))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
if (slave < 1 || slave >= dev->num_slaves ||
|
|
|
|
port < 1 || port > MLX4_MAX_PORTS)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return priv->mfunc.master.vf_admin[slave].enable_smi[port] ==
|
|
|
|
MLX4_VF_SMI_ENABLED;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_vf_get_enable_smi_admin);
|
|
|
|
|
|
|
|
int mlx4_vf_set_enable_smi_admin(struct mlx4_dev *dev, int slave, int port,
|
|
|
|
int enabled)
|
|
|
|
{
|
|
|
|
struct mlx4_priv *priv = mlx4_priv(dev);
|
|
|
|
|
|
|
|
if (slave == mlx4_master_func_num(dev))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (slave < 1 || slave >= dev->num_slaves ||
|
|
|
|
port < 1 || port > MLX4_MAX_PORTS ||
|
|
|
|
enabled < 0 || enabled > 1)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
priv->mfunc.master.vf_admin[slave].enable_smi[port] = enabled;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(mlx4_vf_set_enable_smi_admin);
|