[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.

[PATCH v2 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.


v2:

- note for the future AI reviews: apply this on top of
  the 'common/sfc_efx/base: add VADAPTER statistics for Medford4' series

- addressed https://mails.dpdk.org/archives/dev/2026-August/343072.html
  -- fixed reporting of the factual link speed when running on VFs
  -- remaining notes do not seem to point at factual defects


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   | 90 ++++++++++++++++++++++----
 3 files changed, 88 insertions(+), 12 deletions(-)

-- 
2.47.3

[PATCH v2 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 v2 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 | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/common/sfc_efx/base/efx_np.c b/drivers/common/sfc_efx/base/efx_np.c
index 0e1cd35591..7a30567fe0 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,10 @@ 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))
+		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;
@@ -1050,10 +1055,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);
@@ -1071,6 +1072,23 @@ efx_np_attach(
 		epp->ep_phy_cap_mask |= 1U << EFX_PHY_CAP_AN;
 	}
 
+	/*
+	 * On VFs, 'efx_np_get_fixed_port_props' does not report any link
+	 * speeds; however, 'efx_np_link_state' should provide clues as
+	 * to which link speed is de facto active on the VF. Use this
+	 * clue to provide accurate information to the application.
+	 *
+	 * Also, indicate three basic capabilities that the VF cannot
+	 * manage, but that can be safely assumed to be available.
+	 */
+	if (EFX_PCI_FUNCTION_IS_VF(encp)) {
+		epp->ep_phy_cap_mask = epp->ep_adv_cap_mask;
+
+		epp->ep_phy_cap_mask |= 1U << EFX_PHY_CAP_PAUSE;
+		epp->ep_phy_cap_mask |= 1U << EFX_PHY_CAP_ASYM;
+		epp->ep_phy_cap_mask |= 1U << EFX_PHY_CAP_AN;
+	}
+
 #if EFSYS_OPT_LOOPBACK
 	efx_np_assign_loopback_props(enp);
 #endif /* EFSYS_OPT_LOOPBACK */
-- 
2.47.3

[PATCH v2 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 7a30567fe0..90a5944b85 100644
--- a/drivers/common/sfc_efx/base/efx_np.c
+++ b/drivers/common/sfc_efx/base/efx_np.c
@@ -989,6 +989,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);
@@ -996,6 +997,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 v2 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 90a5944b85..9dbad2e9d1 100644
--- a/drivers/common/sfc_efx/base/efx_np.c
+++ b/drivers/common/sfc_efx/base/efx_np.c
@@ -1551,6 +1551,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);
@@ -1574,9 +1575,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);
 
@@ -1598,12 +1609,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);
@@ -1612,11 +1633,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 v2 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 9dbad2e9d1..a617c05dd2 100644
--- a/drivers/common/sfc_efx/base/efx_np.c
+++ b/drivers/common/sfc_efx/base/efx_np.c
@@ -1727,16 +1727,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 v2 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 v2 0/6] common/sfc_efx/base: add Medford4 VF support

[Stephen Hemminger]

On Wed, 12 Aug 2026 21:10:57 +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.

I decided to hold off on this part, need to look at these AI nits.

Reviewed v3 applied on top of series-38976 plus the net/sfc bugfix
series. check-git-log passes. Two issues below; no Reviewed-by yet.

1. Patch 2/6: PERM derived from the current advertisement

	epp->ep_phy_cap_mask = epp->ep_adv_cap_mask;

ep_adv_cap_mask comes from LINK_STATE_OUT_ADVERTISED_ABILITIES, so
EFX_PHY_CAP_PERM now tracks what the port happens to advertise at
probe rather than what it can support. If that mask has no speed bit
-- no module, or link down at probe -- then in net/sfc

	port->phy_adv_cap_mask = PERM;                 (sfc_port.c:450)
	phy_adv_cap = caps_from_link_speeds(speeds) & phy_adv_cap_mask;
	if ((phy_adv_cap & ~(1 << EFX_PHY_CAP_AN)) == 0)
		return EINVAL;                        (sfc.c:164)

and rte_eth_dev_configure() fails with "No link speeds from mask ...
are supported". The VF stays unusable until it is re-probed with the
link up. A PF is not exposed to this because its PERM comes from
GET_FIXED_PORT_PROPERTIES, which does not vary with link state. The
snapshot is also never refreshed, so a later PF-side advertisement
change leaves the VF's PERM stale.

The comment says link state gives a clue to "which link speed is de
facto active", but the code reads the advertised mask, not
ls.enls_speed / LINK_TECHNOLOGY.

Since medford4_phy_reconfigure() returns early on a VF (no LINK or
ADMIN privilege, so efx_np_link_ctrl() is unreachable), nothing on a
VF can program the PHY anyway and a permissive PERM costs nothing.
Seeding it from the speeds efx_np_cap_map_tech can express would avoid
both problems.

2. Patch 6/6: VF restrictions undocumented

The bare "SR-IOV VF" bullet documents none of what 2/6 to 5/6 encode:

 - flow_ctrl_set with autoneg=0 returns -ENOTSUP (4/6)
 - RTE_ETH_RX_OFFLOAD_KEEP_CRC returns -ENOTSUP (4/6)
 - link status change events are never delivered (3/6)
 - periodic MAC stats DMA unavailable; one-shot uploads instead (5/6)
 - no PHY configuration at all: link_speeds, FEC mode and lane count
   are accepted and silently ignored

The last is the one I would most want written down -- a fixed link
speed on a VF gets no error and no effect. sfc_efx.rst:137 already has
a Limitations section, which looks like the right home, along with the
MCFW 1.4.0.8 floor from 2/6's commit message (older firmware just
fails to probe).

Minor

2/6: efx_np_get_fixed_port_props() now returns 0 without writing
sup_cap_rawp, sup_cap_maskp or loopback_cap_maskp, which are still
__out_bcount_opt / __out_opt. Harmless today, but it is the same
pattern 07/14 of the annotation series changes to __inout. Either make
these __inout_opt or zero them on the VF path.

3/6: the call site comment still reads "Subscribe to link change
events." with no hint it is a no-op for VFs.

5/6: base returns ENOTSUP, net/sfc tests EOPNOTSUPP (sfc_port.c:322).
Equal on Linux and FreeBSD, so fine, just worth knowing.

No findings on 1/6 or 4/6. 4/6's fail label renumbering is correct
(encounter order, chain reaches fail1 from every entry), fcntl is
assigned before the new test, and the net/sfc defaults
(flow_ctrl_autoneg B_TRUE, KEEP_CRC off) trip neither denial.

Not built on my side.

[PATCH v4 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.


v4:

- addressed https://mails.dpdk.org/archives/dev/2026-August/343468.html
  -- patch 2/6: fixed VF PERM mask derivation; all speeds
     from the tech table are now used unconditionally,
     rather than the advertised abilities, which are empty
     when the PF operates in fixed-speed mode; output
     params of efx_np_get_fixed_port_props are now
     zeroed on the VF early-return path
  -- patch 3/6: noted the no-op for VFs in the call
     site comment of efx_np_set_event_mask
  -- patch 6/6: added SR-IOV VF limitations subsection
     to the Limitations section of sfc_efx.rst


v3:

- addressed https://mails.dpdk.org/archives/dev/2026-August/343075.html
  -- patch 6/6: dropped erroneous VADAPTER mention from
     the commit message; added SR-IOV VF to sfc_efx.rst


v2:

- note for the future AI reviews: apply this on top of
  the 'common/sfc_efx/base: add VADAPTER statistics for Medford4' series

- addressed https://mails.dpdk.org/archives/dev/2026-August/343075.html
  -- fixed reporting of the factual link speed when running on VFs
  -- remaining notes do not seem to point at factual defects


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/nics/sfc_efx.rst            |  23 ++++++
 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   | 107 ++++++++++++++++++++++---
 4 files changed, 127 insertions(+), 13 deletions(-)

-- 
2.47.3

[PATCH v4 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 v4 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 | 41 +++++++++++++++++++++++++---
 1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/common/sfc_efx/base/efx_np.c b/drivers/common/sfc_efx/base/efx_np.c
index f8b7e50695..bf0e639704 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,22 @@ 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_rawp != NULL)
+			memset(sup_cap_rawp, 0, MC_CMD_ETH_AN_FIELDS_LEN);
+
+		if (sup_cap_maskp != NULL)
+			*sup_cap_maskp = 0;
+
+		if (loopback_cap_maskp != NULL) {
+			memset(loopback_cap_maskp, 0,
+			    sizeof (*loopback_cap_maskp));
+		}
+
+		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;
@@ -1058,10 +1075,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);
@@ -1079,6 +1092,26 @@ efx_np_attach(
 		epp->ep_phy_cap_mask |= 1U << EFX_PHY_CAP_AN;
 	}
 
+	/*
+	 * On VFs, 'efx_np_get_fixed_port_props' does not report any link
+	 * speeds; indicate the auto-negotiation ability and construct
+	 * the mask of theoretically supported link speed abilities.
+	 *
+	 * Also, indicate two flow control abilities that the VF cannot
+	 * manage, but that can be safely assumed to be available.
+	 */
+	if (EFX_PCI_FUNCTION_IS_VF(encp)) {
+		unsigned int i;
+
+		epp->ep_phy_cap_mask = 1U << EFX_PHY_CAP_AN |
+		    1U << EFX_PHY_CAP_PAUSE | 1U << EFX_PHY_CAP_ASYM;
+
+		for (i = 0; i < EFX_ARRAY_SIZE(efx_np_cap_map_tech); ++i) {
+			epp->ep_phy_cap_mask |=
+			    1U << efx_np_cap_map_tech[i].encm_sw;
+		}
+	}
+
 #if EFSYS_OPT_LOOPBACK
 	efx_np_assign_loopback_props(enp);
 #endif /* EFSYS_OPT_LOOPBACK */
-- 
2.47.3

[PATCH v4 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 | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/common/sfc_efx/base/efx_np.c b/drivers/common/sfc_efx/base/efx_np.c
index bf0e639704..8853ce07c3 100644
--- a/drivers/common/sfc_efx/base/efx_np.c
+++ b/drivers/common/sfc_efx/base/efx_np.c
@@ -1009,6 +1009,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);
@@ -1016,6 +1017,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;
@@ -1139,7 +1144,7 @@ efx_np_attach(
 	 */
 	epp->ep_np_prev_fec_ctrl = MC_CMD_FEC_AUTO;
 
-	/* Subscribe to link change events. */
+	/* Subscribe to link change events; a no-op on VFs. */
 	rc = efx_np_set_event_mask(enp, epp->ep_np_handle, B_TRUE);
 	if (rc != 0)
 		goto fail6;
-- 
2.47.3

[PATCH v4 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 8853ce07c3..90d9ca7918 100644
--- a/drivers/common/sfc_efx/base/efx_np.c
+++ b/drivers/common/sfc_efx/base/efx_np.c
@@ -1573,6 +1573,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);
@@ -1596,9 +1597,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);
 
@@ -1620,12 +1631,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);
@@ -1634,11 +1655,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 v4 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 90d9ca7918..21cdd0acf8 100644
--- a/drivers/common/sfc_efx/base/efx_np.c
+++ b/drivers/common/sfc_efx/base/efx_np.c
@@ -1749,16 +1749,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 v4 6/6] doc: announce VF support of AMD Solarflare X45xx family NICs

[Ivan Malov]

The Solarflare PMD has been updated 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/nics/sfc_efx.rst            | 23 +++++++++++++++++++++++
 doc/guides/rel_notes/release_26_11.rst |  4 ++++
 2 files changed, 27 insertions(+)

diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst
index ae5ef25715..c29719ed7f 100644
--- a/doc/guides/nics/sfc_efx.rst
+++ b/doc/guides/nics/sfc_efx.rst
@@ -113,6 +113,8 @@ SFC EFX PMD has support for:
 
 - SR-IOV PF
 
+- SR-IOV VF
+
 - Port representors (see :ref: switch_representation)
 
 - VLAN stripping (if running firmware variant supports it)
@@ -157,6 +159,27 @@ Another limitation of a equal stride super-buffer mode, imposed by the
 firmware, is that it allows for a single RSS context.
 
 
+SR-IOV VF
+~~~~~~~~~
+
+X4 VF support requires management controller firmware version 1.4.0.8 or later.
+
+When the PMD operates as a VF, the following restrictions apply:
+
+- Link speed, FEC mode and lane count are accepted without
+  error but have no physical effect on the link, which is
+  exclusively under PF control.
+
+- Disabling flow control auto-negotiation is not supported.
+
+- FCS stripping cannot be disabled.
+
+- Link status change events are not delivered.
+
+- Periodic MAC statistics DMA is not available; statistics are
+  collected via one-shot uploads instead.
+
+
 Tunnels support
 ---------------
 
diff --git a/doc/guides/rel_notes/release_26_11.rst b/doc/guides/rel_notes/release_26_11.rst
index 474479babc..a59d2fc8dc 100644
--- a/doc/guides/rel_notes/release_26_11.rst
+++ b/doc/guides/rel_notes/release_26_11.rst
@@ -61,6 +61,10 @@ New Features
     ``use_cni`` or ``use_pinned_map`` is set without ``dp_path``.
     See :doc:`../nics/af_xdp` for more details.
 
+* **Updated Solarflare network driver.**
+
+  * Added VF support on AMD Solarflare X45xx adapters.
+
 
 Removed Items
 -------------
-- 
2.47.3