netvsp: eqe 135 handling clashing with fhr

[erfrimod]

Problems happen when device arrival / removal occur during VF Reconfiguration delays and waits. Modifying the behavior in VF Manager to consider device arrival/removal to indicate that the old VF is gone and the reconfiguration should be abandoned.

Example: EQE 135 arrives -> delay -> FHR -> device removal

• If ManaDeviceRemoved fires during Reconfiguring, clears vf_reconfig_backoff → no more retries
• If ManaDeviceArrived fires while vf_reconfig_backoff is Some, code panics (assert!)
• If the uevent add occurs while state is Reconfiguring, the handling code maps it to Continue → event discarded

[Copilot]

Pull request overview

Adjusts the netvsp VF manager worker’s reconfiguration state machine to better tolerate VF arrival/removal events that occur during VF reconfiguration delays (e.g., EQE 135 + FHR timing), avoiding panics and inappropriate retry behavior.

Changes:

• Treat uevent “device exists” notifications as ManaDeviceArrived even while in Reconfiguring.
• Replace a panic on device arrival during reconfig backoff with “abandon reconfiguration” behavior (clears backoff + logs).
• On device removal, clear any outstanding reconfig backoff (with logging) rather than silently resetting.

[github-actions]

At least one Petri test failed.

[ben-zen]

LGTM

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

[Brian-Perkins]

I think this should always return NextWorkItem::Continue. A device can't arrive until it is removed, and removal will move the state away from Vtl2DeviceState::Reconfiguring.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

openhcl/underhill_core/src/emuplat/netvsp.rs:783

• ManaDeviceArrived is triggered purely by vtl2_device_state == Missing && exists, regardless of action. Since the uevent handler can emit UeventAction::Rescan (and the comment here notes rescans are not a reliable readiness signal), a rescan can spuriously drive an arrival/startup attempt. Consider gating the Missing && exists → ManaDeviceArrived transition on action == UeventAction::Add (and/or explicitly ignoring Rescan) to avoid false-positive arrivals.

                    let exists = Path::new(&device_path).exists();
                    match (vtl2_device_state, exists) {
                        (Vtl2DeviceState::Missing, true) => NextWorkItem::ManaDeviceArrived,
                        (state, false) => {
                            // Tracing to diagnose add that is not acted on due to missing device.
                            if action == UeventAction::Add {
                                 tracelimit::warn_ratelimited!(?state, ?action, exists, %device_path, "uevent received");
                            }