[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th (added brief meeting report from Genivi AMM)
Somehow hadn't noticed that xen-devel was not CC'ed On 20/04/2018, 13:05, "Lars Kurth" <lars.kurth@xxxxxxxxxx> wrote: Hi all, please find attached my notes from the Genivi AMM (as markdown) and PDF. Added Richard (PRQA) and Christoph (ADIT). Regards Lars # Genivi AMM Hypervisor Workshop **Attendees:** around 150 from various vendors and Genivi members ## Opening: Workshop introduction and intention - Gunnar (GENIVI) **Standardisation and process:** the aim of the workshop is to start a process of standardisation of technologies, interfaces, requirements, practices around the use of Hypervisors within Genivi. The kick off was primarily to educate, but in some areas there have already been attempts to start with a proposal (e.g. virtio as standard for I/O). There will be weekly calls to drive a resolution and keep momentum. From a Xen perspective, Artem will attend, but we should get more stake-holders in for specific topics (such as ``` Tuesday, April 10, 10:00 AM CET There is/will be public list (although off-hand I couldn’t find the specific one) Webex Link, Meeting password: hvws ``` The most critical item for now is I/O and whether virtio should become the standard. I discussed with Artem and we didn’t want to be seen to push back too hard at this stage ## Introductory talks: History of Hypevisors - Sang-Bum (Perseus) Market Overview - Franz Walkembach (SysGo) Hypervisor Design and implementation - Ralph (Open Synergy) This talk included quite a lot of inaccuracy: the Xen architecture presented by Ralph very much assumed a typical Xen cloud architecture with no recognition of distributed driver models. It also assumed that QEMU is always part of a Xen system and that we don’t use Hardware extensions. We need to provide feedback and fix inaccuracies in the slide deck from Ralph. Generally, I believe we should pro-actively develop a short paper (the Xen automotive whitepaper seems the best place) which can act as a reference to the likes of Genivi. This should start with where we are now, quote relevant references and point to where we want to be. Failing to do so, will mean that people will make wrong assumptions. ## Requirements HV vendors asking OEMs/adopters/customers/etc to clarify technical requirements Matti (Open Synergy) The general agreement was to start with the requirements from the AGPL white paper, which were also covered in my presentation. ## Technical Topics Virtualization for Multi-core, SoC peripheral and special-purpose CPUs - Artem (EPAM) Audio system design with HVs - Artem (EPAM) Graphics/GPU Sharing (in relation to GSHA project) - Artem (EPAM) (Cyber-)Security enhancements based on virtualization - Sang-Bum (Perseus) This section, together with my introduction in which we demonstrated that we have thought about safety certification, and have a draft plan has shown that we (the Xen community) are ahead of pretty much everyone else by 1-2 years. I believe that this put us into a good position and is also ## Standardisation: virtio Standardization of hypervisor APIs - Matti (Open Synergy) Matti made a case for virtio, which is probably a very bad idea from a Xen perspective (and indeed also from the perspective of QOQOS which is a proprietary hypervisor very similar to what a dom0- less Xen would look like. The main issues are highlighted in https://markmail.org/message/gd7gnkpbsdw54mmm, aka brining in a device emulator and virtio access model requiring full privileges over the VM using the virtio driver. Artem and I briefly discussed whether we should try and raise very loud objections at this stage, and we agreed to just highlight these issues. In response Matti admitted these are issues, but that he would also not want to have to use QEMU (but something much simpler and more lightweight) and that the access model should be resolvable. It was also interesting that Mentor and Windriver could not be made to make a statement whether they would ever support running such drivers in their OSes as guests. I think we should observe for now, and in a few weeks offer to have some of our experts (maybe someone from OpenXT and/or Stefano) to engage and in more detail raise our concerns and convince Matti. Artem will look out for this. **Note:** A meeting to discuss this at a later time that 10:00 is possible ## Standardisation: virtio Health/Debugging/Analysis/Logging - Gunnar Andersson (GENIVI) There was a discussion about logging, benchmarking, basic debug tools. Xen seems to be in good position here and Artem offered to share some material (around the RT whitepaper, which includes information about tooling). ## Conclusion My gut feeling is that Xen is in a strong position within Genivi and that it is worthwhile working with the group. The group works better and seems to be better organized than the AGL virt group. Generally, it was also interesting to see some of the proprietary vendors vigorously attacking the idea that safety certification in an open source context is impossible, which was heavily corrected by other members. Attachment:
2018_GENIVI_XenOverview.pdf Attachment:
Genivi AMM Event Report.pdf _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |