FuSa SIG/Meetings

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
** https://amd.zoom.us/rec/share/7aJKFAH0xjiVHEwpvB7Xb4hIjPsAl_UPEWzAI9S4mTgCJK_vnlCxtq-5LwebE52v.rFqLHBFmW5xSnCXA?startTime=1732633630000 
** Passcode: =Kau9z0a
* 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.
**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.
* 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
* 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.
Category:Safety Certification/FuSa SIG
Category:Safety Certification