FuSa SIG/Meetings: Difference between revisions
From Xen
Jump to navigationJump to search
No edit summary |
No edit summary |
||
(2 intermediate revisions by the same user not shown) | |||
Line 2: | Line 2: | ||
https://lists.xenproject.org/mailman/listinfo/fusa-sig |
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. |
|||
[[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
- 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