| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 22 Jan 2023 16:36:14 +0000
From: "Lucero Palau, Alejandro" <alejandro.lucero-palau@....com>
To: "Lucero Palau, Alejandro" <alejandro.lucero-palau@....com>,
Jiri Pirko <jiri@...nulli.us>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-net-drivers (AMD-Xilinx)" <linux-net-drivers@....com>,
"davem@...emloft.net" <davem@...emloft.net>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"habetsm@...il.com" <habetsm@...il.com>,
"ecree.xilinx@...il.com" <ecree.xilinx@...il.com>
Subject: Re: [PATCH net-next 6/7] sfc: add support for
port_function_hw_addr_get devlink in ef100
On 1/20/23 12:48, Lucero Palau, Alejandro wrote:
> On 1/20/23 11:08, Jiri Pirko wrote:
>> Thu, Jan 19, 2023 at 04:09:27PM CET, alejandro.lucero-palau@....com wrote:
>>> On 1/19/23 12:37, Jiri Pirko wrote:
>>>> Thu, Jan 19, 2023 at 12:31:39PM CET, alejandro.lucero-palau@....com wrote:
>>>>> From: Alejandro Lucero <alejandro.lucero-palau@....com>
>>>>>
>>>>> Using the builtin client handle id infrastructure, this patch adds
>>>>> support for obtaining the mac address linked to mports in ef100. This
>>>>> implies to execute an MCDI command for getting the data from the
>>>>> firmware for each devlink port.
>>>>>
>>>>> Signed-off-by: Alejandro Lucero <alejandro.lucero-palau@....com>
>>>>> ---
>>>>> drivers/net/ethernet/sfc/ef100_nic.c | 27 ++++++++++++++++
>>>>> drivers/net/ethernet/sfc/ef100_nic.h | 1 +
>>>>> drivers/net/ethernet/sfc/ef100_rep.c | 8 +++++
>>>>> drivers/net/ethernet/sfc/ef100_rep.h | 1 +
>>>>> drivers/net/ethernet/sfc/efx_devlink.c | 44 ++++++++++++++++++++++++++
>>>>> 5 files changed, 81 insertions(+)
>>>>>
>>>>> diff --git a/drivers/net/ethernet/sfc/ef100_nic.c b/drivers/net/ethernet/sfc/ef100_nic.c
>>>>> index f4e913593f2b..4400ce622228 100644
>>>>> --- a/drivers/net/ethernet/sfc/ef100_nic.c
>>>>> +++ b/drivers/net/ethernet/sfc/ef100_nic.c
>>>>> @@ -1121,6 +1121,33 @@ static int ef100_probe_main(struct efx_nic *efx)
>>>>> return rc;
>>>>> }
>>>>>
>>>>> +/* MCDI commands are related to the same device issuing them. This function
>>>>> + * allows to do an MCDI command on behalf of another device, mainly PFs setting
>>>>> + * things for VFs.
>>>>> + */
>>>>> +int efx_ef100_lookup_client_id(struct efx_nic *efx, efx_qword_t pciefn, u32 *id)
>>>>> +{
>>>>> + MCDI_DECLARE_BUF(outbuf, MC_CMD_GET_CLIENT_HANDLE_OUT_LEN);
>>>>> + MCDI_DECLARE_BUF(inbuf, MC_CMD_GET_CLIENT_HANDLE_IN_LEN);
>>>>> + u64 pciefn_flat = le64_to_cpu(pciefn.u64[0]);
>>>>> + size_t outlen;
>>>>> + int rc;
>>>>> +
>>>>> + MCDI_SET_DWORD(inbuf, GET_CLIENT_HANDLE_IN_TYPE,
>>>>> + MC_CMD_GET_CLIENT_HANDLE_IN_TYPE_FUNC);
>>>>> + MCDI_SET_QWORD(inbuf, GET_CLIENT_HANDLE_IN_FUNC,
>>>>> + pciefn_flat);
>>>>> +
>>>>> + rc = efx_mcdi_rpc(efx, MC_CMD_GET_CLIENT_HANDLE, inbuf, sizeof(inbuf),
>>>>> + outbuf, sizeof(outbuf), &outlen);
>>>>> + if (rc)
>>>>> + return rc;
>>>>> + if (outlen < sizeof(outbuf))
>>>>> + return -EIO;
>>>>> + *id = MCDI_DWORD(outbuf, GET_CLIENT_HANDLE_OUT_HANDLE);
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> int ef100_probe_netdev_pf(struct efx_nic *efx)
>>>>> {
>>>>> struct ef100_nic_data *nic_data = efx->nic_data;
>>>>> diff --git a/drivers/net/ethernet/sfc/ef100_nic.h b/drivers/net/ethernet/sfc/ef100_nic.h
>>>>> index e59044072333..f1ed481c1260 100644
>>>>> --- a/drivers/net/ethernet/sfc/ef100_nic.h
>>>>> +++ b/drivers/net/ethernet/sfc/ef100_nic.h
>>>>> @@ -94,4 +94,5 @@ int ef100_filter_table_probe(struct efx_nic *efx);
>>>>>
>>>>> int ef100_get_mac_address(struct efx_nic *efx, u8 *mac_address,
>>>>> int client_handle, bool empty_ok);
>>>>> +int efx_ef100_lookup_client_id(struct efx_nic *efx, efx_qword_t pciefn, u32 *id);
>>>>> #endif /* EFX_EF100_NIC_H */
>>>>> diff --git a/drivers/net/ethernet/sfc/ef100_rep.c b/drivers/net/ethernet/sfc/ef100_rep.c
>>>>> index ff0c8da61919..974c9ff901a0 100644
>>>>> --- a/drivers/net/ethernet/sfc/ef100_rep.c
>>>>> +++ b/drivers/net/ethernet/sfc/ef100_rep.c
>>>>> @@ -362,6 +362,14 @@ bool ef100_mport_on_local_intf(struct efx_nic *efx,
>>>>> mport_desc->interface_idx == nic_data->local_mae_intf;
>>>>> }
>>>>>
>>>>> +bool ef100_mport_is_vf(struct mae_mport_desc *mport_desc)
>>>>> +{
>>>>> + bool pcie_func;
>>>>> +
>>>>> + pcie_func = ef100_mport_is_pcie_vnic(mport_desc);
>>>>> + return pcie_func && (mport_desc->vf_idx != MAE_MPORT_DESC_VF_IDX_NULL);
>>>>> +}
>>>>> +
>>>>> void efx_ef100_init_reps(struct efx_nic *efx)
>>>>> {
>>>>> struct ef100_nic_data *nic_data = efx->nic_data;
>>>>> diff --git a/drivers/net/ethernet/sfc/ef100_rep.h b/drivers/net/ethernet/sfc/ef100_rep.h
>>>>> index 9cca41614982..74853ccbc937 100644
>>>>> --- a/drivers/net/ethernet/sfc/ef100_rep.h
>>>>> +++ b/drivers/net/ethernet/sfc/ef100_rep.h
>>>>> @@ -75,4 +75,5 @@ void efx_ef100_fini_reps(struct efx_nic *efx);
>>>>> struct mae_mport_desc;
>>>>> bool ef100_mport_on_local_intf(struct efx_nic *efx,
>>>>> struct mae_mport_desc *mport_desc);
>>>>> +bool ef100_mport_is_vf(struct mae_mport_desc *mport_desc);
>>>>> #endif /* EF100_REP_H */
>>>>> diff --git a/drivers/net/ethernet/sfc/efx_devlink.c b/drivers/net/ethernet/sfc/efx_devlink.c
>>>>> index bb19d3ad7ffd..2a57c4f6d2b2 100644
>>>>> --- a/drivers/net/ethernet/sfc/efx_devlink.c
>>>>> +++ b/drivers/net/ethernet/sfc/efx_devlink.c
>>>>> @@ -429,6 +429,49 @@ static int efx_devlink_add_port(struct efx_nic *efx,
>>>>> return err;
>>>>> }
>>>>>
>>>>> +static int efx_devlink_port_addr_get(struct devlink_port *port, u8 *hw_addr,
>>>>> + int *hw_addr_len,
>>>>> + struct netlink_ext_ack *extack)
>>>>> +{
>>>>> + struct efx_devlink *devlink = devlink_priv(port->devlink);
>>>>> + struct mae_mport_desc *mport_desc;
>>>>> + efx_qword_t pciefn;
>>>>> + u32 client_id;
>>>>> + int rc = 0;
>>>>> +
>>>>> + mport_desc = efx_mae_get_mport(devlink->efx, port->index);
>>>> I may be missing something, where do you fail with -EOPNOTSUPP
>>>> in case this is called for PHYSICAL port ?
>>>>
>>> We do not create a devlink port for the physical port.
>> Well, you do:
>>
>> + switch (mport->mport_type) {
>> + case MAE_MPORT_DESC_MPORT_TYPE_NET_PORT:
>> + attrs.flavour = DEVLINK_PORT_FLAVOUR_PHYSICAL;
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Right.
>
> I was relying on devlink-port output which does not show the physical
> port in my machine and completely forgot about it.
>
> I'm a bit confused at this point. Let me look at this further.
>
The reason devlink show/info does not report the PHYSICAL port is
simple: current code does not create a devlink port for such mport.
I say current code because in my first implementation (not upstreamed) I
just created devlink ports when the mports where enumerated, what turned
out to be a bit complicated for dealing with VFs creation/destruction,
and after looking at how other drivers do this, just before the related
netdev is registered, I went for that same approach. That leaves no
option for the physical mport registered.
I could add that creation at PF devlink port creation, if we consider
this a necessity. I know the ideal devlink support in our driver should
likely be more devlink design compliant, but it is also true drivers
should make use of it as decided for fulfilling their necessities as
long as it does not create confusion to users. Our current devlink
necessity is for dealing with setting VFs mac address as required during
previous representors patchset review:
https://lore.kernel.org/netdev/20220728092008.2117846e@kernel.org/
Do you see a problem not creating such a devlink port by now?
>> + attrs.phys.port_number = mport->port_idx;
>> + devlink_port_attrs_set(dl_port, &attrs);
>> + break;
>> + case MAE_MPORT_DESC_MPORT_TYPE_VNIC:
>> + if (mport->vf_idx != MAE_MPORT_DESC_VF_IDX_NULL) {
>> + devlink_port_attrs_pci_vf_set(dl_port, 0, mport->pf_idx,
>> + mport->vf_idx,
>> + external);
>> + } else {
>> + devlink_port_attrs_pci_pf_set(dl_port, 0, mport->pf_idx,
>> + external);
>> + }
>> + break;
>>
>>
>>
>>
>>> I'm aware this is not "fully compliant" with devlink design idea, just
>>> trying to use it for our current urgent necessities by now.
>>>
>>> Do you think this could be a problem?
>> If you create port flavour = DEVLINK_PORT_FLAVOUR_PHYSICAL and it is not
>> uplink, it is a problem :)
>>
>>
>>
>>>>> + if (!mport_desc)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + if (!ef100_mport_on_local_intf(devlink->efx, mport_desc))
>>>>> + goto out;
>>>>> +
>>>>> + if (ef100_mport_is_vf(mport_desc))
>>>>> + EFX_POPULATE_QWORD_3(pciefn,
>>>>> + PCIE_FUNCTION_PF, PCIE_FUNCTION_PF_NULL,
>>>>> + PCIE_FUNCTION_VF, mport_desc->vf_idx,
>>>>> + PCIE_FUNCTION_INTF, PCIE_INTERFACE_CALLER);
>>>>> + else
>>>>> + EFX_POPULATE_QWORD_3(pciefn,
>>>>> + PCIE_FUNCTION_PF, mport_desc->pf_idx,
>>>>> + PCIE_FUNCTION_VF, PCIE_FUNCTION_VF_NULL,
>>>>> + PCIE_FUNCTION_INTF, PCIE_INTERFACE_CALLER);
>>>>> +
>>>>> + rc = efx_ef100_lookup_client_id(devlink->efx, pciefn, &client_id);
>>>>> + if (rc) {
>>>>> + netif_err(devlink->efx, drv, devlink->efx->net_dev,
>>>>> + "Failed to get client ID for port index %u, rc %d\n",
>>>>> + port->index, rc);
>>>>> + return rc;
>>>>> + }
>>>>> +
>>>>> + rc = ef100_get_mac_address(devlink->efx, hw_addr, client_id, true);
>>>>> +out:
>>>>> + *hw_addr_len = ETH_ALEN;
>>>>> +
>>>>> + return rc;
>>>>> +}
>>>>> +
>>>>> static int efx_devlink_info_get(struct devlink *devlink,
>>>>> struct devlink_info_req *req,
>>>>> struct netlink_ext_ack *extack)
>>>>> @@ -442,6 +485,7 @@ static int efx_devlink_info_get(struct devlink *devlink,
>>>>>
>>>>> static const struct devlink_ops sfc_devlink_ops = {
>>>>> .info_get = efx_devlink_info_get,
>>>>> + .port_function_hw_addr_get = efx_devlink_port_addr_get,
>>>>> };
>>>>>
>>>>> static struct devlink_port *ef100_set_devlink_port(struct efx_nic *efx, u32 idx)
>>>>> --
>>>>> 2.17.1
>>>>>
Powered by blists - more mailing lists