Re: [PATCH 0/5] Rundown MRSW lock and device removal fixes

["Tu Dinh" <ngoc-tu.dinh@xxxxxxxxxx>]

Hi,

On 17/04/2026 14:45, Owen Smith wrote:
> 
> Do these changes work without the matching xennet changes?
> Do the xennet changes work without these changes?
> 
> (i.e. is it safe to apply these without the xennet patches or the xennet 
> patches
>   without these patches?)
> 
> Owen
> 

I've only tested the xenvif and xennet changes together. Running them 
separately hasn't really been tested. But the lockup fixes should be 
independent of each other, as they fix different steps in the surprise 
removal process.

For information, the status of each patch should be as following 
(dependent patches are grouped together)

(xenvif)
* Check Fragment->Entry before calling RevokeForeignAccess
     - Self-contained.

* Watch BACKEND/state key for eject status
     - Lockup fix, self-contained. It triggers surprise removal instead 
of orderly removal when using `vif-unplug force=true`.

* Update IRQL annotations
     - Should go before the MRSW patch for IRQL correctness.
* Implement rundown-based MRSW lock
     - Self-contained except for "Update IRQL annotations". I haven't 
really tested this patch by itself without the lockup fixes. It's 
possible that running things at a lower IRQL would cause certain lockup 
problems to be easier to surface, but I can't confirm one way or another.

* Trace worker thread wake events
     - Self-contained.

(xennet)
* Signal surprise removal support during registration
     - Self-contained.

* Call AdapterDisable during NdisDevicePnPEventSurpriseRemoved
     - Lockup fix, self-contained, doesn't cause a dependency on xenvif 
or vice versa. But the surprise removal code path (fixed here) isn't 
entered without the xenvif patch "Watch BACKEND/state key for eject status".

NB: "Call AdapterDisable during NdisDevicePnPEventSurpriseRemoved" is 
very much a hack, since neither the MiniportDevicePnPEventNotify 
documentation nor the driver samples advocate stopping the datapath at 
this point. But given the lack of hang detection and response in 
xenvif/xennet, this is the best I could come up with to avoid lockups 
during surprise removal.

> ________________________________________
> From: win-pv-devel <win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx> on behalf of 
> Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>
> Sent: 16 April 2026 12:09 PM
> To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Tu Dinh; Owen Smith
> Subject: [PATCH 0/5] Rundown MRSW lock and device removal fixes
> 
> Patches 1 and 2 are fixes for various lockups encountered during
> surprise removal.
> 
> Patch 3 is an annotation prerequisite for Patch 4, which replaces the
> current MRSW lock with a simpler one.
> 
> Patch 5 is only for debugging purposes.
> 
> To be used together with matching Xennet surprise removal patches.
> 
> Tu Dinh (5):
>    Check Fragment->Entry before calling RevokeForeignAccess
>    Watch BACKEND/state key for eject status
>    Update IRQL annotations
>    Implement rundown-based MRSW lock
>    Trace worker thread wake events
> 
>   src/xenvif/controller.c  |   5 +-
>   src/xenvif/fdo.c         |   6 +-
>   src/xenvif/frontend.c    |  36 +--
>   src/xenvif/frontend.h    |  18 +-
>   src/xenvif/mrsw.h        | 530 ++++++++++++++++++++++-----------------
>   src/xenvif/receiver.c    |  24 +-
>   src/xenvif/receiver.h    |  14 +-
>   src/xenvif/transmitter.c |  25 +-
>   src/xenvif/transmitter.h |   6 +-
>   src/xenvif/vif.c         |  73 +++---
>   10 files changed, 409 insertions(+), 328 deletions(-)
> 
> --
> 2.53.0.windows.2
> 
> 
> --
> Ngoc Tu Dinh | Vates XCP-ng Developer
> 
> XCP-ng & Xen Orchestra - Vates solutions
> 
> web: https://vates.tech
> 
> 



--
Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech