[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: XenVif div by zero on Tx path after resume.
On 28/04/2022 16:23, Martin Harvey wrote: -----Original Message----- From: Durrant, Paul <xadimgnik@xxxxxxxxx> Sent: 25 April 2022 10:15 To: Martin Harvey <martin.harvey@xxxxxxxxxx>; paul@xxxxxxx; win-pv-devel@xxxxxxxxxxxxxxxxxxxx Subject: Re: XenVif div by zero on Tx path after resume.It then calls SyncRelease(). This runs the 'late' suspend callbacks and terminates the DPCs on other CPUs, thus allowing threads to be scheduled. It then lowers IRQL on the current CPU, which should mean a fall back to PASSIVE as SuspendTrigger() is only ever called from the dedicated thread (running FdoSuspend()).Nice try. The mutual exclusion for the late callbacks depends on the other CPU's still spinning at dispatch - since plenty of other network processing also happens at dispatch. You need to complete *all* the late callbacks before releasing *any* of the CPU's from our DPC. One more step duly added in RFC patch. Ok, right... I broke it in: ----- commit 9b7a47317031ddf5fab74311b24756c05bac72ae Author: Paul Durrant <pdurrant@xxxxxxxxxx> Date: Mon Nov 30 13:52:09 2020 +0000Re-work the code in sync.c to provide per-CPU 'early' and 'late' callbacks... ... and then use these to drive the XENBUS_SUSPEND callbacks, rather than them being called directly from SuspendTrigger().Since the clients of the XENBUS_SUSPEND interface only expect one invocation of each callback, rather then one per-CPU, they are only invoked from the sync.c callback for CPU 0. A subsequent patch will introduce a function that must be called from the 'early' callback for each CPU.NOTE: The call to KeGetCurrentProcessorNumberEx() made in SyncRelease() is relocated to __SyncRelease(), as that is the place where the CPU index is actually used. Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx> ----- I'll take a look at the RFC patch. Thanks for figuring this out. Paul MH.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |