[PATCH 0/6] common/sfc_efx/base: add Medford4 VF support

[PATCH 0/6] common/sfc_efx/base: add Medford4 VF support

[Ivan Malov]

This series enables DPDK to use the sfc driver
on a Medford4 VF alongside the PF.

The first patch wires EVB switch operations into the Medford4
libefx implementation, allowing the PF to manage VFs.

Starting with MCFW 1.4.0.8, VFs may use the netport MCDI for basic port
configuration, though several operations remain restricted. The
remaining four patches address each restriction: dummy fixed
port properties, suppressed event subscription, denied FCS
and flow control, and ENOTSUP for periodic MAC stats DMA.

This series depends on the VADAPTER statistics series.

Ivan Malov (6):
  common/sfc_efx/base: let Medford4 PF manage VFs
  common/sfc_efx/base: indicate dummy netport properties on VF
  common/sfc_efx/base: skip netport event subscriptions on VFs
  common/sfc_efx/base: deny tuning FCS and flow control to VFs
  common/sfc_efx/base: deny periodic MAC stats delivery to VFs
  doc: announce VF support of AMD Solarflare X45xx family NICs

 doc/guides/rel_notes/release_26_11.rst |  4 ++
 drivers/common/sfc_efx/base/efx_evb.c  |  6 ++
 drivers/common/sfc_efx/base/efx_np.c   | 91 ++++++++++++++++++++++----
 3 files changed, 89 insertions(+), 12 deletions(-)

-- 
2.47.3

[PATCH 1/6] common/sfc_efx/base: let Medford4 PF manage VFs

[Ivan Malov]

When the user binds the PF to 'vfio-pci', enables SR-IOV
and instantiates a VF, looking to attach both the PF and
the VF to DPDK, the DPDK driver has to instantiate the
EVB switch on the PF. Wire the necessary methods into
the Medford4 EVB implementation in libefx.

Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
Reviewed-by: Andy Moreton <andy.moreton@amd.com>
---
 drivers/common/sfc_efx/base/efx_evb.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/common/sfc_efx/base/efx_evb.c b/drivers/common/sfc_efx/base/efx_evb.c
index 5933c5d883..79db77c635 100644
--- a/drivers/common/sfc_efx/base/efx_evb.c
+++ b/drivers/common/sfc_efx/base/efx_evb.c
@@ -107,6 +107,12 @@ efx_evb_init(
 		break;
 #endif /* EFSYS_OPT_RIVERHEAD */
 
+#if EFSYS_OPT_MEDFORD4
+	case EFX_FAMILY_MEDFORD4:
+		eeop = &__efx_evb_ef10_ops;
+		break;
+#endif /* EFSYS_OPT_MEDFORD4 */
+
 	default:
 		EFSYS_ASSERT(0);
 		rc = ENOTSUP;
-- 
2.47.3

[PATCH 2/6] common/sfc_efx/base: indicate dummy netport properties on VF

[Ivan Malov]

Starting with MCFW version 1.4.0.8, Medford4 adapters support the use
of the netport MCDI for port configuration by a VF; however, the MCDI
which retrieves fixed port properties is not permitted for use by VFs.

Fill in dummy values sufficient for the DPDK driver to start on a VF.

Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
Reviewed-by: Andy Moreton <andy.moreton@amd.com>
---
 drivers/common/sfc_efx/base/efx_np.c | 27 +++++++++++++++++++++++----
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/common/sfc_efx/base/efx_np.c b/drivers/common/sfc_efx/base/efx_np.c
index 5f5ec86647..e05e2cb487 100644
--- a/drivers/common/sfc_efx/base/efx_np.c
+++ b/drivers/common/sfc_efx/base/efx_np.c
@@ -240,6 +240,7 @@ efx_np_get_fixed_port_props(
 	__out_opt		uint32_t *sup_cap_maskp,
 	__out_opt		efx_qword_t *loopback_cap_maskp)
 {
+	const efx_nic_cfg_t *encp = &enp->en_nic_cfg;
 	EFX_MCDI_DECLARE_BUF(payload,
 	    MC_CMD_GET_FIXED_PORT_PROPERTIES_IN_LEN,
 	    MC_CMD_GET_FIXED_PORT_PROPERTIES_OUT_V2_LEN);
@@ -247,6 +248,28 @@ efx_np_get_fixed_port_props(
 	efx_mcdi_req_t req;
 	efx_rc_t rc;
 
+	/* VFs do not allow access to the fixed port data. */
+	if (EFX_PCI_FUNCTION_IS_VF(encp)) {
+		if (sup_cap_maskp != NULL) {
+			/*
+			 * Indicate a dummy link speed mode, as the
+			 * DPDK driver expects to see at least one.
+			 */
+			*sup_cap_maskp = 1U << EFX_PHY_CAP_1000FDX;
+
+			/*
+			 * Indicate three basic capabilities that
+			 * a VF cannot manage, but that can be
+			 * safely assumed to be available.
+			 */
+			*sup_cap_maskp |= 1U << EFX_PHY_CAP_PAUSE;
+			*sup_cap_maskp |= 1U << EFX_PHY_CAP_ASYM;
+			*sup_cap_maskp |= 1U << EFX_PHY_CAP_AN;
+		}
+
+		return (0);
+	}
+
 	req.emr_out_length = MC_CMD_GET_FIXED_PORT_PROPERTIES_OUT_V2_LEN;
 	req.emr_in_length = MC_CMD_GET_FIXED_PORT_PROPERTIES_IN_LEN;
 	req.emr_cmd = MC_CMD_GET_FIXED_PORT_PROPERTIES;
@@ -1048,10 +1071,6 @@ efx_np_attach(
 	if (rc != 0)
 		goto fail1;
 
-	/*
-	 * FIXME: This may need revisiting for VFs, which
-	 * don't necessarily have access to these details.
-	 */
 	rc = efx_np_get_fixed_port_props(enp, epp->ep_np_handle,
 		    epp->ep_np_cap_data_raw, &epp->ep_phy_cap_mask,
 		    &epp->ep_np_loopback_cap_mask);
-- 
2.47.3

[PATCH 3/6] common/sfc_efx/base: skip netport event subscriptions on VFs

[Ivan Malov]

Subscribing to netport events is not permitted on VFs.

Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
Reviewed-by: Andy Moreton <andy.moreton@amd.com>
---
 drivers/common/sfc_efx/base/efx_np.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/common/sfc_efx/base/efx_np.c b/drivers/common/sfc_efx/base/efx_np.c
index e05e2cb487..1563fbae37 100644
--- a/drivers/common/sfc_efx/base/efx_np.c
+++ b/drivers/common/sfc_efx/base/efx_np.c
@@ -1005,6 +1005,7 @@ efx_np_set_event_mask(
 	__in		efx_np_handle_t nph,
 	__in		boolean_t want_linkchange_events)
 {
+	const efx_nic_cfg_t *encp = &enp->en_nic_cfg;
 	EFX_MCDI_DECLARE_BUF(payload,
 	    MC_CMD_SET_NETPORT_EVENTS_MASK_IN_LEN,
 	    MC_CMD_SET_NETPORT_EVENTS_MASK_OUT_LEN);
@@ -1012,6 +1013,10 @@ efx_np_set_event_mask(
 	efx_dword_t dword;
 	efx_rc_t rc;
 
+	/* VFs do not allow subscription to link change events. */
+	if (EFX_PCI_FUNCTION_IS_VF(encp))
+		return (0);
+
 	req.emr_out_length = MC_CMD_SET_NETPORT_EVENTS_MASK_OUT_LEN;
 	req.emr_in_length = MC_CMD_SET_NETPORT_EVENTS_MASK_IN_LEN;
 	req.emr_cmd = MC_CMD_SET_NETPORT_EVENTS_MASK;
-- 
2.47.3

[PATCH 4/6] common/sfc_efx/base: deny tuning FCS and flow control to VFs

[Ivan Malov]

Medford4 VFs can configure MAC settings via the netport MCDI,
but controlling FCS stripping and setting flow control mode
are off limits. Express all this in code to allow the DPDK
driver to start and forbid changes to FCS and flow control.

For what it's worth, changing MTU is allowed on VFs, but
the value must be less than or equal to the PF's MTU.

Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
Reviewed-by: Andy Moreton <andy.moreton@amd.com>
---
 drivers/common/sfc_efx/base/efx_np.c | 41 +++++++++++++++++++++++-----
 1 file changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/common/sfc_efx/base/efx_np.c b/drivers/common/sfc_efx/base/efx_np.c
index 1563fbae37..6d9c62fcda 100644
--- a/drivers/common/sfc_efx/base/efx_np.c
+++ b/drivers/common/sfc_efx/base/efx_np.c
@@ -1548,6 +1548,7 @@ efx_np_mac_ctrl(
 	__in		efx_np_handle_t nph,
 	__in		const efx_np_mac_ctrl_t *mc)
 {
+	const efx_nic_cfg_t *encp = &enp->en_nic_cfg;
 	EFX_MCDI_DECLARE_BUF(payload,
 	    MC_CMD_MAC_CTRL_IN_LEN,
 	    MC_CMD_MAC_CTRL_OUT_LEN);
@@ -1571,9 +1572,19 @@ efx_np_mac_ctrl(
 	if (mc->enmc_set_pdu_only != B_FALSE)
 		goto skip_full_reconfigure;
 
-	cfg |= 1U << MC_CMD_MAC_CONFIG_OPTIONS_CFG_INCLUDE_FCS;
-	if (mc->enmc_include_fcs != B_FALSE)
-		flags |= 1U << MC_CMD_MAC_FLAGS_FLAG_INCLUDE_FCS;
+	/* Only PFs can control FCS stripping. */
+	if (EFX_PCI_FUNCTION_IS_PF(encp)) {
+		cfg |= 1U << MC_CMD_MAC_CONFIG_OPTIONS_CFG_INCLUDE_FCS;
+		if (mc->enmc_include_fcs != B_FALSE)
+			flags |= 1U << MC_CMD_MAC_FLAGS_FLAG_INCLUDE_FCS;
+	} else if (mc->enmc_include_fcs != B_FALSE) {
+		/*
+		 * Assume that FCS stripping being enabled is the driver's
+		 * default expectation and deny disabling it to VFs.
+		 */
+		rc = ENOTSUP;
+		goto fail1;
+	}
 
 	MCDI_IN_SET_DWORD(req, MAC_CTRL_IN_FLAGS, flags);
 
@@ -1595,12 +1606,22 @@ efx_np_mac_ctrl(
 			break;
 		default:
 			rc = EINVAL;
-			goto fail1;
+			goto fail2;
 		}
 	}
 
-	cfg |= 1U << MC_CMD_MAC_CONFIG_OPTIONS_CFG_FCNTL;
-	MCDI_IN_SET_DWORD(req, MAC_CTRL_IN_FCNTL, fcntl);
+	/* Only PFs can change flow control settings. */
+	if (EFX_PCI_FUNCTION_IS_PF(encp)) {
+		cfg |= 1U << MC_CMD_MAC_CONFIG_OPTIONS_CFG_FCNTL;
+		MCDI_IN_SET_DWORD(req, MAC_CTRL_IN_FCNTL, fcntl);
+	} else if (fcntl != MC_CMD_FCNTL_AUTO) {
+		/*
+		 * Assume that flow control auto-negotiation is the driver's
+		 * default expectation and deny any attempts to override it.
+		 */
+		rc = ENOTSUP;
+		goto fail3;
+	}
 
 skip_full_reconfigure:
 	MCDI_IN_SET_DWORD(req, MAC_CTRL_IN_V2_CONTROL_FLAGS, cfg);
@@ -1609,11 +1630,17 @@ efx_np_mac_ctrl(
 
 	if (req.emr_rc != 0) {
 		rc = req.emr_rc;
-		goto fail2;
+		goto fail4;
 	}
 
 	return (0);
 
+fail4:
+	EFSYS_PROBE(fail4);
+
+fail3:
+	EFSYS_PROBE(fail3);
+
 fail2:
 	EFSYS_PROBE(fail2);
 
-- 
2.47.3

[PATCH 5/6] common/sfc_efx/base: deny periodic MAC stats delivery to VFs

[Ivan Malov]

Currently, requesting periodic DMA results in an EACCES error being
returned, but the DPDK driver expects ENOTSUP to handle the
situation gracefully. Implement proper error indication.

Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
Reviewed-by: Andy Moreton <andy.moreton@amd.com>
---
 drivers/common/sfc_efx/base/efx_np.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/common/sfc_efx/base/efx_np.c b/drivers/common/sfc_efx/base/efx_np.c
index 6d9c62fcda..dafb1dfee6 100644
--- a/drivers/common/sfc_efx/base/efx_np.c
+++ b/drivers/common/sfc_efx/base/efx_np.c
@@ -1724,16 +1724,32 @@ efx_np_mac_stats(
 	efx_mcdi_execute(enp, &req);
 
 	if (req.emr_rc != 0) {
+		const efx_nic_cfg_t *encp = &enp->en_nic_cfg;
+
+		if (req.emr_rc == EACCES && (enable | events) &&
+		    EFX_PCI_FUNCTION_IS_VF(encp)) {
+			/*
+			 * VFs cannot request periodic DMAing of statistics.
+			 * Indicate 'ENOTSUP' for the DPDK driver to handle
+			 * this gracefully and stick with one-time uploads.
+			 */
+			rc = ENOTSUP;
+			goto fail3;
+		}
+
 		/* EF10: Expect ENOENT if no DMA queues are initialised */
 		if ((req.emr_rc != ENOENT) ||
 		    (enp->en_rx_qcount + enp->en_tx_qcount != 0)) {
 			rc = req.emr_rc;
-			goto fail3;
+			goto fail4;
 		}
 	}
 
 	return (0);
 
+fail4:
+	EFSYS_PROBE(fail4);
+
 fail3:
 	EFSYS_PROBE(fail3);
 
-- 
2.47.3

[PATCH 6/6] doc: announce VF support of AMD Solarflare X45xx family NICs

[Ivan Malov]

The Solarflare PMD has been updated to support VADAPTER statistics and to
let the user attach to the X4 VFs (created by the PF that is attached
either to the DPDK application or to the Solarflare Linux net driver).

Signed-off-by: Ivan Malov <ivan.malov@arknetworks.am>
Reviewed-by: Viacheslav Galaktionov <viacheslav.galaktionov@arknetworks.am>
---
 doc/guides/rel_notes/release_26_11.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/doc/guides/rel_notes/release_26_11.rst b/doc/guides/rel_notes/release_26_11.rst
index c8cc86295d..a4a8a67d8c 100644
--- a/doc/guides/rel_notes/release_26_11.rst
+++ b/doc/guides/rel_notes/release_26_11.rst
@@ -55,6 +55,10 @@ New Features
      Also, make sure to start the actual text at the margin.
      =======================================================
 
+* **Updated Solarflare network driver.**
+
+  * Added VF support on AMD Solarflare X45xx adapters.
+
 
 Removed Items
 -------------
-- 
2.47.3

Re: [PATCH 0/6] common/sfc_efx/base: add Medford4 VF support

[Stephen Hemminger]

On Tue, 11 Aug 2026 21:50:19 +0400
Ivan Malov <ivan.malov@arknetworks.am> wrote:

> This series enables DPDK to use the sfc driver
> on a Medford4 VF alongside the PF.
> 
> The first patch wires EVB switch operations into the Medford4
> libefx implementation, allowing the PF to manage VFs.
> 
> Starting with MCFW 1.4.0.8, VFs may use the netport MCDI for basic port
> configuration, though several operations remain restricted. The
> remaining four patches address each restriction: dummy fixed
> port properties, suppressed event subscription, denied FCS
> and flow control, and ENOTSUP for periodic MAC stats DMA.
> 
> This series depends on the VADAPTER statistics series.
> 
> Ivan Malov (6):
>   common/sfc_efx/base: let Medford4 PF manage VFs
>   common/sfc_efx/base: indicate dummy netport properties on VF
>   common/sfc_efx/base: skip netport event subscriptions on VFs
>   common/sfc_efx/base: deny tuning FCS and flow control to VFs
>   common/sfc_efx/base: deny periodic MAC stats delivery to VFs
>   doc: announce VF support of AMD Solarflare X45xx family NICs
> 
>  doc/guides/rel_notes/release_26_11.rst |  4 ++
>  drivers/common/sfc_efx/base/efx_evb.c  |  6 ++
>  drivers/common/sfc_efx/base/efx_np.c   | 91 ++++++++++++++++++++++----
>  3 files changed, 89 insertions(+), 12 deletions(-)
> 

Some AI feedback, no real errors

Series: [PATCH 0/6] SFC Medford4 VF support (Ivan Malov)
Reviewed against DPDK main @ c1a46b9; all 6 patches apply with git am.
Full-series build (gcc 13, -Dwerror=true) is clean.

Patch 2/6: common/sfc_efx/base: indicate dummy netport properties on VF

Warning: The dummy capability mask makes the VF report a 1 Gbps port.

  efx_np_get_fixed_port_props() returns only EFX_PHY_CAP_1000FDX as the
  supported link speed. That value flows to epp->ep_phy_cap_mask, then to
  sfc_port_attach() via efx_phy_adv_cap_get(EFX_PHY_CAP_PERM), and finally
  to dev_info.speed_capa in sfc_dev_infos_get(). A VF on an X4522/X4542
  will therefore advertise RTE_ETH_LINK_SPEED_1G and nothing else.

  The consequence is not cosmetic. sfc_check_conf() computes

      sa->port.phy_adv_cap = sfc_phy_cap_from_link_speeds(conf->link_speeds)
                             & sa->port.phy_adv_cap_mask;

  and fails configure with EINVAL if the result is empty. An application
  that requests a specific speed (RTE_ETH_LINK_SPEED_25G, for example)
  rather than autoneg cannot configure the VF at all, and one that reads
  speed_capa to pick a speed will pick 1G.

  efx_np_link_state() is called a few lines later in efx_np_attach() and
  does work on a VF; ls.enls_adv_cap_mask holds the real advertised
  abilities. Suggest deriving the VF capability mask from that instead of
  hardcoding 1000FDX, e.g. fold ls.enls_adv_cap_mask into
  epp->ep_phy_cap_mask for VFs after the efx_np_link_state() call.

Info: sup_cap_rawp and loopback_cap_maskp are left untouched on the VF
  path. This is not a use-of-uninitialised bug -- efx_nic_create() uses
  EFSYS_KMEM_ALLOC, which is rte_zmalloc, so epp->ep_np_cap_data_raw and
  ep_np_loopback_cap_mask are zero. Worth a note in the commit message
  that zero is the intended value, since efx_np_assign_lane_counts() and
  efx_np_assign_loopback_props() both consume them.

Info: The dummy mask sets EFX_PHY_CAP_AN, and efx_np_attach() sets the
  same bit again from ls.enls_an_supported at line 1026. Harmless, but
  one of the two is redundant.

Patch 6/6: doc: announce VF support of AMD Solarflare X45xx family NICs

Warning: Commit message claims work that is not in this series.

  "The Solarflare PMD has been updated to support VADAPTER statistics and
  to let the user attach to the X4 VFs". There is no VADAPTER statistics
  change in this series, and grep finds no vadaptor/VADAPTER reference in
  drivers/net/sfc or in the release notes hunk. Either drop that clause or
  add the corresponding release notes entry.

Warning: doc/guides/nics/sfc_efx.rst is not updated.

  The feature list has "SR-IOV PF" but not VF. The features matrix
  (doc/guides/nics/features/sfc.ini) already has SR-IOV = Y, so only the
  prose list is stale. Since the series makes VF attach work on Medford4,
  the driver guide should say so.