arm64: gic: Use IPI test checking for the LPI tests
The LPI code validates a result similarly to the IPI tests, by checking if
the target CPU received the interrupt with the expected interrupt number.
However, the LPI tests invent their own way of checking the test results by
creating a global struct (lpi_stats), using a separate interrupt handler
(lpi_handler) and test function (check_lpi_stats).
There are several areas that can be improved in the LPI code, which are
already covered by the IPI tests:
- check_lpi_stats() doesn't take into account that the target CPU can
receive the correct interrupt multiple times.
- check_lpi_stats() doesn't take into the account the scenarios where all
online CPUs can receive the interrupt, but the target CPU is the last CPU
that touches lpi_stats.observed.
- Insufficient or missing memory synchronization.
Instead of duplicating code, let's convert the LPI tests to use
check_acked() and the same interrupt handler as the IPI tests, which has
been renamed to irq_handler() to avoid any confusion.
check_lpi_stats() has been replaced with check_acked() which, together with
using irq_handler(), instantly gives us more correctness checks and proper
memory synchronization between threads. lpi_stats.expected has been
replaced by the CPU mask and the expected interrupt number arguments to
check_acked(), with no change in semantics.
lpi_handler() aborted the test if the interrupt number was not an LPI. This
was changed in favor of allowing the test to continue, as it will fail in
check_acked(), but possibly print information useful for debugging. If the
test receives spurious interrupts, those are reported via report_info() at
the end of the test for consistency with the IPI tests, which don't treat
spurious interrupts as critical errors.
In the spirit of code reuse, secondary_lpi_tests() has been replaced with
ipi_recv() because the two are now identical; ipi_recv() has been renamed
to irq_recv(), similarly to irq_handler(), to avoid confusion.
CC: Eric Auger <eric.auger@redhat.com>
Signed-off-by:
Alexandru Elisei <alexandru.elisei@arm.com>
Loading
Please register or sign in to comment