On 03/10/2024 3:20 pm, Roger Pau Monne wrote:
> The current dpci logic relies on a softirq being executed as a side effect of
> the cpu_notifier_call_chain() call in the code path that offlines the target
> CPU. However the call to cpu_notifier_call_chain() won't trigger any softirq
> processing, and even if it did, such processing should be done after all
> interrupts have been migrated off the current CPU, otherwise new pending dpci
> interrupts could still appear.
>
> Current ASSERT in
"Currently the ASSERT() in"
> the cpu callback notifier is fairly easy to trigger by doing
> CPU offline from a PVH dom0.
>
> Solve this by instead moving out any dpci interrupts pending processing once
> the CPU is dead. This might introduce more latency than attempting to drain
> before the CPU is put offline, but it's less complex, and CPU online/offline
> is
> not a common action. Any extra introduced latency should be tolerable.
>
> Fixes: f6dd295381f4 ('dpci: replace tasklet with softirq')
> Signed-off-by: Roger Pau Monné <[email protected]>
Yeah, I'm not concerned with minor extra latency in the offline path.
In production it's used 0% of the time to many many significant figures.
Acked-by: Andrew Cooper <[email protected]>
