All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
To: <xen-devel@lists.xenproject.org>
Cc: Ayan Kumar Halder <ayan.kumar.halder@amd.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Julien Grall <julien@xen.org>,
	Bertrand Marquis <bertrand.marquis@arm.com>,
	Michal Orzel <michal.orzel@amd.com>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	Artem Mygaiev <artem_mygaiev@epam.com>,
	<matthew.l.weber3@boeing.com>, <harunobu.kurokawa.dn@renesas.com>
Subject: [XEN PATCH v1 1/2] docs/fusa: add coverage_gap.rst tabulating vGICv3 LCOV exclusions
Date: Tue, 21 Jul 2026 13:47:28 +0100	[thread overview]
Message-ID: <20260721124729.868630-2-ayan.kumar.halder@amd.com> (raw)
In-Reply-To: <20260721124729.868630-1-ayan.kumar.halder@amd.com>

Some code is unreachable by design (for example a defensive default arm
of a switch that no caller can reach) and can therefore never be
executed by any test. Such code shows up as a permanent gap in the
coverage report even though it is correct. To keep the report meaningful
we exclude these regions from coverage, but every exclusion must be
justified and reviewable so that a genuine gap is never hidden behind an
LCOV marker. This file is that record: it gives each exclusion a stable
id, points at the excluded source, and states why the code is
unreachable and what would make it reachable again.

Record the LCOV_EXCL regions in xen/arch/arm/vgic-v3.c as a table with
columns coverage_gap_id, file, line numbers and SHA, plus a
justification taken from each COV-GAP-VGICV3 "Reason for exclusion".

Use upstream xen (xenbits/master) line ranges and SHA, with line numbers
given in vgic-v3.c:Lstart-Lend notation, and state explicitly that each
excluded default arm becomes reachable only if a caller is modified to
forward an offset the handler has no case for, at which point the
exclusion must be removed. Wire the file into the docs/fusa toctree.

Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
---
The coverage gap justification may be used to state why a piece of code
cannot be tested within the scope of our safety and it cannot be removed
as well. Thus, we use the justification to analyse and document the
behavior of untested code in safety certifiable Xen.

 docs/fusa/coverage_gap.rst | 41 ++++++++++++++++++++++++++++++++++++++
 docs/fusa/index.rst        |  1 +
 2 files changed, 42 insertions(+)
 create mode 100644 docs/fusa/coverage_gap.rst

diff --git a/docs/fusa/coverage_gap.rst b/docs/fusa/coverage_gap.rst
new file mode 100644
index 0000000000..9d14f7b264
--- /dev/null
+++ b/docs/fusa/coverage_gap.rst
@@ -0,0 +1,41 @@
+.. SPDX-License-Identifier: CC-BY-4.0
+
+Coverage gaps
+=============
+
+This table documents the ``LCOV_EXCL`` regions in the Xen source. Each excluded
+region is tagged in the source with a ``COV-GAP-<COMPONENT>-NNN`` marker that
+matches an entry below. A region is excluded from the coverage report only when
+it is unreachable by design, so it can never be reported as covered.
+
+.. list-table::
+   :header-rows: 1
+   :widths: 15 25 10 12 38
+
+   * - coverage_gap_id
+     - file
+     - line numbers
+     - SHA
+     - justification
+   * - COV-GAP-VGICV3-001
+     - xen/arch/arm/vgic-v3.c
+     - L796-L800
+     - 351d41e8aecc3f7566a0baa7b4066d06dedd7113
+     - Both callers select the register offset with their own ``switch`` and
+       forward only offsets the handler has an explicit ``case`` for, so no
+       forwarded offset can fall through to ``default:``. (The SGI_base-frame
+       ``GICR_*`` offsets one caller forwards are numerically equal to the
+       ``GICD_*`` offsets the handler cases on.) The ``default:`` is kept as
+       defensive programming; it becomes reachable only if a caller is
+       modified to forward an offset the handler has no ``case`` for, at
+       which point this exclusion must be removed.
+   * - COV-GAP-VGICV3-002
+     - xen/arch/arm/vgic-v3.c
+     - L954-L958
+     - 351d41e8aecc3f7566a0baa7b4066d06dedd7113
+     - Same design as COV-GAP-VGICV3-001, for the write path: both callers
+       forward only offsets the handler has an explicit ``case`` for, so the
+       ``default:`` arm cannot be reached and is kept as defensive
+       programming; it becomes reachable only if a caller is modified to
+       forward an offset the handler has no ``case`` for, at which point this
+       exclusion must be removed.
diff --git a/docs/fusa/index.rst b/docs/fusa/index.rst
index 5f1e8acfc4..dd5ca4dd95 100644
--- a/docs/fusa/index.rst
+++ b/docs/fusa/index.rst
@@ -7,3 +7,4 @@ Functional Safety documentation
    :maxdepth: 2
 
    reqs/index
+   coverage_gap
-- 
2.25.1



  reply	other threads:[~2026-07-21 12:48 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21 12:47 [XEN PATCH v1 0/2] docs/fusa: coverage-gap justifications and generic timer arch spec Ayan Kumar Halder
2026-07-21 12:47 ` Ayan Kumar Halder [this message]
2026-07-21 13:00   ` [XEN PATCH v1 1/2] docs/fusa: add coverage_gap.rst tabulating vGICv3 LCOV exclusions Jan Beulich
2026-07-21 13:10     ` Halder, Ayan Kumar
2026-07-21 12:47 ` [XEN PATCH v1 2/2] docs/fusa: add generic timer arch spec with ASCII diagrams Ayan Kumar Halder
2026-07-21 13:52   ` [EXTERNAL] " Weber (US), Matthew L

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260721124729.868630-2-ayan.kumar.halder@amd.com \
    --to=ayan.kumar.halder@amd.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=artem_mygaiev@epam.com \
    --cc=bertrand.marquis@arm.com \
    --cc=harunobu.kurokawa.dn@renesas.com \
    --cc=julien@xen.org \
    --cc=matthew.l.weber3@boeing.com \
    --cc=michal.orzel@amd.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.