From: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
To: <xen-devel@lists.xenproject.org>
Cc: <sstabellini@kernel.org>, <bertrand.marquis@arm.com>,
<michal.orzel@amd.com>, <volodymyr_babchuk@epam.com>,
<mark.brown@parrylabs.com>, <matthew.l.weber3@boeing.com>,
<sookyung.ahn@boeing.com>,
Ayan Kumar Halder <ayan.kumar.halder@amd.com>
Subject: [RFC PATCH v1] imagebuilder: Add a script to check the sanity of device tree
Date: Mon, 1 Sep 2025 13:31:03 +0100 [thread overview]
Message-ID: <20250901123103.11418-1-ayan.kumar.halder@amd.com> (raw)
Xen gives a panic if certain nodes are not present in the device tree. In order
to prevent this panic, scripts/dt_sanity.py is written so that it checks if the
node/s are present. If the node/s are not present, the script gives an error.
User is expected to run the script against the device tree before booting Xen
with dtb.
Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com>
---
Hi,
In some of the discussions with the safety experts and upstream folks, one issue
that kept coming up is there are lots of ‘faulty system configuration’ and
‘impossible conditions’ checks in Xen. While these conditions can rarely occur,
Xen would panic if any of such condition does occur.
For example, during bootup, Xen parses the device tree .
It checks if the device tree nodes are present for timer, interrupt-controller,
memory, cpu, etc. If these nodes are not present, Xen panics.
As part of safety certification, we have 3 aims :-
1. We want to reduce the instances where Xen can panic. This is to improve the
robustness.
2. We need to define a safe state when a fault is triggered in Xen. As faults
(like the one mentioned here) are triggered during boot time and it is due to
incorrect system configuration in device tree, it is hard to define a safe state.
3. Avoid validating all the instances of system configuration errors. By having
an external tool, we push the responsibility to the system integrator. The system
integrator needs to run the tool to validate all the properties that Xen checks
for. This can be a justification for the coverage gap for those checks in Xen.
Thus, I have come up with the attached python script. In the script, we parse the
device tree to check if the nodes with the compatible properties (as specified in
config file) are present. If not, the script will throw an error.
README.md | 13 +++++++++++++
scripts/dt_sanity.py | 33 +++++++++++++++++++++++++++++++++
2 files changed, 46 insertions(+)
create mode 100644 scripts/dt_sanity.py
diff --git a/README.md b/README.md
index 7b68cf5..413de3f 100644
--- a/README.md
+++ b/README.md
@@ -456,3 +456,16 @@ This section defines config file debug options
- DBG_FDT_PRINT_CHOSEN specifies that U-Boot script command to print DT "chosen"
node will be added to the boot script.
+
+## dt_sanity.py
+
+This script parses xen device tree source and checks if the required nodes are
+present. If not, the script gives an error.
+
+To use it, first write a config file like `config` where you can keep the
+compatible strings to be checked:
+
+```
+arm,gic-v3
+arm,armv8-timer
+```
diff --git a/scripts/dt_sanity.py b/scripts/dt_sanity.py
new file mode 100644
index 0000000..171947f
--- /dev/null
+++ b/scripts/dt_sanity.py
@@ -0,0 +1,33 @@
+import argparse
+from pydevicetree import Devicetree
+import sys
+
+def load_compatible_strings(config_path):
+ with open(config_path, 'r') as file:
+ return [line.strip() for line in file if line.strip()]
+
+def check_compatible_nodes(dts_path):
+ # Parse the DTS file
+ tree = Devicetree.parseFile(dts_path)
+
+ # Search nodes for compatible properties in the global array
+ for compatible in compatible_strings:
+ nodes = tree.match(compatible)
+ if len(nodes) == 0:
+ print(f"Error: Node with compatible '{compatible}' not found.")
+ sys.exit(1)
+
+if __name__ == "__main__":
+ # Set up argument parser
+ parser = argparse.ArgumentParser(description="Check for Xen specific nodes in a DTS file.")
+ parser.add_argument("dts_file", help="Path to the DTS file")
+ parser.add_argument("config_file", help="Path to the configuration file with compatible strings")
+
+ # Parse arguments
+ args = parser.parse_args()
+
+ # Load compatible strings from the config file
+ compatible_strings = load_compatible_strings(args.config_file)
+
+ # Use the provided DTS file path
+ check_compatible_nodes(args.dts_file)
--
2.25.1
next reply other threads:[~2025-09-01 12:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-01 12:31 Ayan Kumar Halder [this message]
2025-09-01 13:03 ` [RFC PATCH v1] imagebuilder: Add a script to check the sanity of device tree Andrew Cooper
2025-09-01 13:17 ` Orzel, Michal
2025-09-01 13:51 ` Ayan Kumar Halder
2025-09-04 14:16 ` Ayan Kumar Halder
2025-09-22 17:10 ` Ayan Kumar Halder
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=20250901123103.11418-1-ayan.kumar.halder@amd.com \
--to=ayan.kumar.halder@amd.com \
--cc=bertrand.marquis@arm.com \
--cc=mark.brown@parrylabs.com \
--cc=matthew.l.weber3@boeing.com \
--cc=michal.orzel@amd.com \
--cc=sookyung.ahn@boeing.com \
--cc=sstabellini@kernel.org \
--cc=volodymyr_babchuk@epam.com \
--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.