FuSa SIG/Meetings: Difference between revisions

From Xen
Jump to navigationJump to search
No edit summary
No edit summary
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
The Xen FuSa SIG meets bi-weekly. Please join the mailing list to request the latest information about the meeting details:
Please contact lars dot kurth at xenproject dot org or Artem_Mygaiev at epam dot com if you want to be added to the regular FuSa SIG Meetings


https://lists.xenproject.org/mailman/listinfo/fusa-sig
Note: Eventually this will be an open community call. However at the beginning, we need to control numbers until we have made sufficient progress.


* 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.


[[Category:Safety Certification/FuSa SIG]]
[[Category:Safety Certification/FuSa SIG]]

Latest revision as of 15:22, 13 December 2024

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


  • 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.
Retrieved from "https://wiki.xenproject.org/index.php?title=FuSa_SIG/Meetings&oldid=20063"