[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
Description: 2018_GENIVI_XenOverview.pdf

Attachment: Genivi AMM Event Report.pdf
Description: Genivi AMM Event Report.pdf

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.