On 7/23/2026 7:51 AM, Tomasz Lichwala wrote:
...
+/**
+ * ixgbevf_hv_read_links_e610 - read link status from PCI config space
+ * @hw: pointer to hardware structure
+ * @links_reg: pointer to store read value
+ *
+ * On Hyper-V E610 VFs the VFLINKS register does not carry valid link speed.
+ * Instead, link status is exposed through emulated PCI config space at offset
+ * 0x209 in VFLINKS register format.
+ *
+ * Return: 0 on success, negative error code on failure.
+ */
+static s32 ixgbevf_hv_read_links_e610(struct ixgbe_hw *hw, u32 *links_reg)
+{
+ struct ixgbevf_adapter *adapter = hw->back;
+
+#if IS_ENABLED(CONFIG_PCI_MMCONFIG)
+ u8 data[IXGBE_HV_LINK_STATUS_SIZE];
+
+ for (int i = 0; i < IXGBE_HV_LINK_STATUS_SIZE; i++) {
+ int ret = pci_read_config_byte(adapter->pdev,
+ IXGBE_HV_LINK_STATUS_OFFSET + i,
+ &data[i]);
+ if (ret)
+ return pcibios_err_to_errno(ret);
+ }
+
+ *links_reg = get_unaligned_le32(data);
+ return 0;
+#else
+ dev_err_once(&adapter->pdev->dev, "cannot read link status, PCI_MMCONFIG is
required for Hyper-V\n");
+ return -EOPNOTSUPP;
+#endif
+}
I ran Sashiko locally on this and it reported the following:
Should a failed link read here return a fatal error to check_link, or
report link down and return 0?
When built without CONFIG_PCI_MMCONFIG this returns -EOPNOTSUPP on every
call, and it also returns an error on any persistent
pci_read_config_byte() failure.
/**
* ixgbevf_hv_check_mac_link_vf - check link
* @hw: pointer to private hardware struct
@@ -909,6 +946,7 @@ static s32 ixgbevf_check_mac_link_vf(struct ixgbe_hw *hw,
* @autoneg_wait_to_complete: unused
*
* Hyper-V variant; there is no mailbox communication.
+ * For E610 VFs, link status is read from emulated PCI config space.
*/
static s32 ixgbevf_hv_check_mac_link_vf(struct ixgbe_hw *hw,
ixgbe_link_speed *speed,
@@ -923,13 +961,32 @@ static s32 ixgbevf_hv_check_mac_link_vf(struct ixgbe_hw
*hw,
if (!mbx->ops.check_for_rst(hw) || !mbx->timeout)
mac->get_link_status = true;
+ /* E610 VFs always read link status from emulated PCI config space
+ * because VFLINKS does not carry valid speed for these devices.
+ * Skip get_link_status caching since PCI config reads are cheap.
+ */
+ if (mac->type == ixgbe_mac_e610_vf) {
+ s32 ret = ixgbevf_hv_read_links_e610(hw, &links_reg);
+
+ if (ret) {
+ *link_up = false;
+ *speed = IXGBE_LINK_SPEED_UNKNOWN;
+ return ret;
+ }
+ goto decode;
+ }
+
Can this cause a repeating reset loop on the degraded configuration?
The non-zero return propagates up through mac.ops.check_link() into
ixgbevf_watchdog_update_link():
err = hw->mac.ops.check_link(hw, &link_speed, &link_up, false);
...
if (err && time_after(jiffies, adapter->last_reset + (10 * HZ))) {
set_bit(__IXGBEVF_RESET_REQUESTED, &adapter->state);
link_up = false;
}
A device reset cannot make CONFIG_PCI_MMCONFIG appear at compile time, nor
fix a persistent config-space read failure, so wouldn't every watchdog
cycle re-arm __IXGBEVF_RESET_REQUESTED roughly every 10 seconds, leaving
the interface permanently down and continuously resetting?
Before this patch the Hyper-V check_link callback always returned 0, so no
reset request was triggered. Would returning 0 with link_up=false and
speed IXGBE_LINK_SPEED_UNKNOWN for the unsupported/degraded case avoid the
loop?
One related note: the dev_err_once() reads as a benign one-time notice,
but the underlying -EOPNOTSUPP is returned on every poll and drives the
repeating reset behavior above.
Thanks,
Tony
