mirror of
https://chromium.googlesource.com/crosvm/crosvm
synced 2025-02-11 04:26:38 +00:00
9880100a3f
In order to avoid deadlocks (when a Vcpu thread has locked the ioapic and the ioapic sends a AddMsiRoute signal to the main thread which itself may be busy trying to call service_irq) KvmSplitIrqChip defers IRQs by using vector of delayed IRQs and queuing it up for the next main thread loop spin. The problem is that next loop spin will ever happen if there will be any *unrelated* trigger event to be serviced which means IRQ reinjection may take really long time, at least longer than some devices may assume before timeout. Instead of relaying on non-deterministic mechanism, make sure the next trigger event for main thread is around the corner by: - adding a new event - strictly related to processing delayed IRQs - adding a new token type in main thread and correlate the new event occurrence with process_delayed_irq_events() irqchip call - writing to the new event as soon as new IRQ is added to the delayed vector This makes sure that delayed IRQs (if present) are always on main loop's TODO list. BUG=b:184871003 TEST=boot guest using crosvm --split-irqchip flag and check if IOAPIC related IRQs are working Change-Id: I89e731f19a7fa5215cd4a57fa5c94a89a7c9161a Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3494286 Reviewed-by: Colin Downs-Razouk <colindr@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Tomasz Nowicki <tnowicki@google.com> |
||
|---|---|---|
| .. | ||
| src | ||
| .build_test_serial | ||
| Cargo.toml | ||