FuSa SIG/Meetings
From Xen
Jump to navigationJump to search
The Xen FuSa SIG meets bi-weekly. Please join the mailing list to request the latest information about the meeting details:
https://lists.xenproject.org/mailman/listinfo/fusa-sig
- 26/11/2024 - Fault injection tests
- 12/12/2024 - Fault injection tests further analysis
- Minutes
- We went over "Xen FuSa WG - Fault injection".
- There were some concerns about how we should call the hardware faults , but nothing major. Francesco will put his review comments.
- Software internal faults - There were concerns that Xen has lots of panic(). So, Artem mentioned that this needs to be re visisted. Bertrand and Francisco said that we need to have a safety concept first and as part of that define in which scenarios we want the system to panic. I mentioned that we do have the reqs and we can add more reqs to define the situations which needs to be taken care by the system integrator (AoU). Thus, we can remove the panic() in those situations. We have AI 2 and 3 related to this.
- Software external faults - Bertrand mentioned that if the domain tries to access memory outside of it's scope, Xen should not allow the domain to continue the execution.
- We went over "Xen FuSa WG - Fault injection".
- Minutes
- Further Action items
- 1. Ayan will refine the fault injection analysis and will send it to the group. Francesco/others will review it. Subsequently, I will send it to xen-devel.
- 2. We will come up with some market requirements to say what the system integrator is expected to check. Francesco can help us to define the safety concept. Bertrand can help with the reviews.
- 3. As a follow up on 2, Artem/others can provide some analysis on the existing panic()/bug_on()/ etc to see if it makes sense from safety perspective. We can understand which panic() we want to keep and which we want to remove (as we have a rationale that this condition is not possible as we have defined the requirements - for eg minimum memory) and which can be changed to propagate error.
- Further Action items
- 7/1/2025 - Safety concept
- 1. Following from the previous discussion, Francesco sent out the safety concept.
- 2. Clarified Error detection, Error reaction, Safe state and other terminologies.
- 3. Meeting details - https://amd.zoom.us/rec/share/4sXTMFWXhS4CVNam3QGCBR7RqUZ4kQuXFKLDWLLWKu4u4wt806PCH5MiZ0-3K5JU.og5i2ZXZWHHfjHnQ?startTime=1736262249000
- Passcode: @8v9brr%
- Further Action items
- 1. Move the error types from fault injection to safety concept.
- 2. Polish the safety concept with some examples
- Further Action items
- 21/1/2025 - FMEA and Safety element out of context
- 1. Meeting details - https://amd.zoom.us/rec/share/eunH2NyUSrTLh88IrIilo0RiR0cSBc7c1V_Z2LxgpIziieqsz_yY17wIP2C5he8w.vvbXnzE3hlFrZymq
- Passcode: RjQC#$y2
- 2. FMEA - It is analysis based on the existing code/design and/or historic bugs, to understand what might go wrong. The end result of FMEA is to improve the verification plan.
- 3. Safety element out of context - The safety manual should describe the assumptions of the hardware/VMs and the specific contexts of the VM.
- 4/2/2025 - Safety processes
- 1. Meeting details - https://amd.zoom.us/rec/share/6pHb6vjlSXdU1ttNJbssHkvBGF9kkUbREyWxd9XT4yCdaMCQwMxFRu2O_p3spaBY.EXe8dpx0PUTtL_ex
- Passcode: +Gii573c
- 2. Mapping of the upstream community process with Quality management (ISO 9001) and safety processes (ISO-26262)
- 3. Gap analysis between the upstream community and safety for change management, configuration management and justification for safety element out of context.
- Further Action items
- 1. Artem to share the xls and slides.
- 2. Community to decide where to place the safety artefacts.
- Further Action items
- 18/2/2025 - MCDC
- 1. Meeting details - https://amd.zoom.us/rec/share/PzszvBy5aUqxDgSzHETIf87nv6GbxAAjzjeTf-jsJrmetJqxgOfVj2AdGPtSOpPH.0cx5dIjjT9JBeWzd
- Passcode: 1y7+m##q
- 2. MCDC can be substituted with Branch coverage with some explanations for conditions.
- 3. Missing coverage can be explained with a rationale. You can group some of the scenarios (for hardware error which are impossible to reproduce)
- Further Action items
- 1. Francesco will prepare a POC to showcase gcc-gcov and llvm-lcov for MCDC on a simple opensource project. This can be showcased to the xen-devel as a potential tool to be used on Xen.
- Further Action items
- 4/3/2025 - Xen's error/exception handling
- 1. Meeting details - https://amd.zoom.us/rec/share/2crZUB5DHrHsnsFwkfWx9yQrpmuNyaSc_Iw7uVqY_4Z3KmzpGeScMun938lmHaXJ.knTRzzyfQ4j4Umoh
- Passcode: Gx9Bw8$Q
- 2. Similar to requirements, we need to write interface_exceptions.rst stating "Xen shall return a data abort to a domain when it does not find an entry in the stage2 page tables for the memory accessed".
- 3. A safety certified Xen needs to log all instances of exception injections to domains.
- 4. Only for Error, Xen will stop the domain.
- 5. System integrator will define the safe domains and non safe domain's behaviour. Xen will inject exception (as per the behaviour defined in interface_exceptions.rst). There can be numerous scenarios in which these exceptions can occur. Ultimately it is system integrator's decision to say whether a domain should be crashed on receiving undef/abort exception or if the domain is allowed to continue.
- 6. System integrator will decide which errors are fatal from platform's perspective. Xen will just return errors for the interfaces (which needs to be documented).
- 7. Xen will stop the domains when it receives SError.
- Further Action items
- 1. Ayan will prepare interface_exceptions.rst
- 2. Artem will prepare the top down approach for Xen's error handling behaviour.
- Further Action items
- 18/3/2025 - Domain roles vs safe/unsafe VM
- 1. Meeting details - https://amd.zoom.us/rec/share/1m2nS4LN9DRK1TLtDNWPiRmJx6HkjMx11wZZfq-dXXao3lZyIn6IsZbk7kYd6B-9.XDq_fx32CCduVjub
- Passcode: 4!=WqGO*
- 2. We should define interference and restrictions for each type of communication means (ie device assignment, shared memory, event channel, grants).
- 3. A higher SIL domain cannot be interfered by a lower SIL domain
- 4. We can have different safety integrity levels of VMs in the system.
- 1/4/2025 - Validation tests for booting and firmware requirements
- 1. Meeting details - https://amd.zoom.us/rec/share/YcUzGCL8EkNzXba_PSLVt2t35WuKkolDlUR6LQxB7ATFcCtZP9fBUcsNtguAWXhN.L733dwGoOMRVQ3hy (sorry we lost the first few minutes)
- Passcode: tx78*%AT
- 2. For booting requirements --- Here the requirements correspond to one or more lines of code which is self contained.
- Approach 1 - One can hack Qemu (to print logs) when particular registers are touched by Xen (to enable MMU, D cache, etc). However, note that Qemu is just an emulation platform (and Xen is used as safety out of context), so we can offload the responsibility to the system integrator to validate the behavior.
- Approach 2 - One can take a dump of registers from gdb, etc which will show that Xen has turned on the registers.
- Approach 3 - One can use coverage and existing boot logs and code inspection to validate these requirements.
- 3. For firmware requirements - Xen interfaces with TF-A Using PSCI
- Approach 1 - We can make a modification to Xen to disable the piece of code (turning on the secondary cpus) and from the boot logs confirm that the secondary cpus are not turned on (Negative testing)
- Approach 2 - Hack ATF so that it prints a log or something, Similarly one can provide a faulty DTB to prove that Xen is parsing certain properties from DTB which it expects to find.
- Approach 3 - Coverage + bootlogs
- 4. Tool to document coverage gap - This needs to be asked in wider forum.
- Further Action items
- 1. A presentation/demo from Volodymyr on Fuzzer, MCDC and automated test generation from symbols. (for the future)
- Further Action items