(star) This contains meeting minutes.  If meetings are cancelled this would be noted here.  Some dates are missing minutes but ideas are always captured on the main project pages here.


Minute takers according to this page 


February 12th, 2019

Participants:

Agenda:

Minutes:

February 5, 2019

Participants:

apologies

Agenda:

Minutes:

January 29, 2018

Participants:

Minutes

January 22, 2019

Participants:

Minutes

  1. Franz suggested GENIVI community looking at RISC V architecture – this might become a production grade at some point
  2. Gunnar goes over last call’s minutes
  3. GHS: Nikola cannot join anymore because he changed position, GHS said they are interested in continuing their participation to the work
  4. Bernhard don’t have updates on SEL2 / SP805 yet
    1. Mentioned that discussion can happen with ARM engineers on WDT – but this is part of “supervisor” not hypervisor. This can be reviewed in scope of SBSA
    2. SEL2 – maybe some spec updates? Not yet
  5. Gunnar pointed out the need to take time schedules more aggressively
    1. Philippe suggested to use May 14-16 AMM in Munich as a milestone for some 1st version release and holding technical workshop on virtualization & spec review
    2. Gunnar requests for topics/proposals for presentations on GENIVI AMM (Artem wants to suggest reviewing pvif as alternative to virtio)
  6. Reviewing Virtual Device Categories table yet
    1. Block storage – no updates yet from Kai, Gunnar is reviewing goals and approach. One of the main un-covered topics is “automotive-grade persistency management” – does this imply some requirements on hypervisor level? Artem – hypervisor just shall not interfere. Gunnar – there may be 2 approaches: write-through with “privileged” processes or going through all system layers as usual. Kai – write down the requirements. Discussion continues into discussing API stability for all scenarios. Gunnar – does virtio provide everything needed for technical implementation of abovementioned? Kai – no, probably not, it does not allow applying policy, etc. Need to define what is missing, requirements, etc. From example of 2D GPU, Kai is asking – from this table it is not clear if virtio fits requirements. Gunnar – requirements must be checked against virtio spec. Kai – requirements as of now implying some design choices which may not be correct. Gunnar – yes, but requirements are there to support different implied designs, not to enforce them. Goal is to make a generic specification which can be tailored for a target system.

January 15, 2019

Participants:


Minutes

Fairly short sync up on a few topics and planning the work going forward.

Gunnar: I'm thinking of writing a short introduction chapter for SCMI to make the proposal more concrete.  Hopefully this sparks feedback and it's an important chapter.

Artem: SCMI is being updated by ARM. So we should take that into account.
I think we should participate in that kind of spec update.

Bernhard joining...

Bernhard: I can find the right contact people for this.

Artem: Is there any updates on security?
...like SEL2 implementation for ARMv8

Artem: For your information we just upstreamed to OPTEE and to TrustZone support for previous architectures.

Bernhard: On the Watchdog topic:
...The SBSA, Server Based Systems Architecture, includes Watchdog info that could be relevant.
...I can find a team from ARM to give more information about this.

Artem: Is SBSA only for enterprise domain?

Bernhard: No we write it independently. It is part of the architecture itself.

Gunnar: I notice Anup's intro text links to an ARM spec on the watchdog part but that linked document seems chip-specific (I mean ARM-architecture
specific). I think for a cross-platform specification we're looking for something slightly different.

Gunnar: Of course wherever we end up seeing platform differences for a feature, that may be an outcome as well
...if common abstraction is not appropriate for some reason. The important thing is to clarify this and document it.

CES:

Some reflections...  What was most shown and discussed at CES? (Autonomous vehicles)
and what was the most interesting for you (Gunnar:  For me 1000+ people in GENIVI/NAB showcase event.  Not the easiest
place for good business discussions (loud) but it's a fun big meetup place at least.).  Also, LGE keynote.

December 11, 2018

Participants:


Notes from HV meeting 2018-12-11

Gunnar: Did you perform the action to decide on support (or not) for SCMI-for-sensors proposal?

... SCMI being discussed in OpenSynergy

Dmitry: ...comppany working to form an opinion, will come back.
Dmitry: It seems to be more features on backends side clocks and power domains
...Is SCMI an appropriate protocol
Gunnar: Yes, the specification itself highlights those features. The proposal that this will be repurposed as a standard sensors API is the new idea.

Kai: Not so much focus on that right now
Kai: feedback and a review should be possible

Alex: ... need to give feedback
Alex - noo need for input because EPAM

Gunnar: SCMI - more comments?

Matt: I'd rather have Bernhard comment on it.

Vasco: I need to look into this. Kind of a new topic.

Gunnar: Still open question for me is Intel suppt? I'd consider contacting ACRN project as a start.

Matt: I'd like to think that it can be adopted by Intel, will check if we have had any feedback.
Will check with Bernhard Rill.

Virtualization spec

Dmitry's input:

SHALL/MUST Reuse definitions from VIRTIO

Gunnar: I notice a mix of terms here.
Dmitry: Yes, shall and must are the same thing.

MUST seems to be used as positive and SHALL NOT used as negative (in VIRTIO)


Discussion with Kai on block device

Some features might not be covered by VIRTIO in enough detail.

Kai: trim command is worthwhile to describe.

Gunnar: OK can we then try this as a start - describe trim command in
detail, specification, could be requirements... It should be concrete -
we're writing a specification...

Gunnar: I want to get the AGL review off the backlog, it's been open long
enough. Please read the paper, figure out what is useful / not useful in
the context we are working. Just like source code we should reuse already
done work.... (Just like others may reuse what we produce in the virt
platform spec).

Gunnar: More from backlog - the architecture & requirements work thread has stopped because of lack of input and previous driver Sriram is busy.

Gunnar: Have you looked at this within Bosch?  Vasco?

Vasco:  I will consider this

- Architecture
- Use case
- Requirements

Gunnar: You can address it from any angle you like of the above 3, it will lead to the kind of results we mean here.

Action (all): AGL paper read through (again), see links


December 4, 2018

Participants:


Minutes (TBD)


November 27, 2018

Participants

Dmitry: I have written 2D and 3D graphics requirements on the Specification draft page.

Reviewing Dmitrys input...

Dmitry: 2D is quite clear
Gunnar: The 2D chapter references VIRTIO 1.0 from 2015. Is it up to date?
Dmitry: Yes, I think so. Not much change (in 2D area)
Dmitry: VIRTIO-VIRGL - empty reference for now. There is no spec to point to yet. I can only refer to kernel source etc.
...hope to see something coming here.

Gunnar: Great start, comprehensive and detailed work!
Gunnar: But it is very minimalistic, which we want of course, but maybe too much.
... We need to write each topic/chapter names so that people can see what each requirement is about.

Dmitry: OK, I will fix that

Gunnar: We should also write some introduction text to topics.  Put in a paragraph or so at least.   If a particular topic is not covered in VIRTIO remember that we still need to put a placeholder title in there.

Gunnar: Asking the group generally: usefulness of specification? Are we still doing the right thing?
Franz: In some areas PikeOS has its own APIs and we do not use VIRTIO
Gunnar: Understood, and that's a choice anyone is free to make. To be clear we're not saying everything must be exactly according to VIRTIO, but of course other proposals must be laid out if they are going to affect standards work.

...Going through the table to review last week's discussion.
Gunnar. USB (repeat) Any device role? Device role? Anyone?

Gunnar: What are the use cases, you all work in real projects so you are the ones that might know of any.

Franz: I see mostly connection mobile phone, provide streaming video via hone.
Gunnar: That is normally still car in host role and phone in device role I believe.
Gunnar: Anyone else know of any case where car has device-role?
(none answered)

Gunnar: Artem, Updates?
Artem: Sorry been travelling. Will be more up to date next week.

Vasco (chat): Have to drop off...

Going through the table a bit more.  Mostly we need to collect and consolidate what has already been created.

Gunnar: Bernhard, updates or thoughts?  Your ARM colleagues have provided good input the last few weeks, for example about what lies in the future, i.e. what's still open topics in virtualization.
Bernhard: Sorry, back from vacation, also need to catch up on notes first.

Gunnar:  (smile)  OK, no problem.  Let's reconvene next week with more energy.  We now have a good draft that will lead the way for other topics. 




From Tuesday, October 23 to date

iteration on the following wiki page content

Tuesday October 16, 2018

Participants

Apologies

Minutes

Quick de-brief

Gunnar: Questions coming up after ARM presentation?

Artem: No immediate questions from me.  Julien is main ARM Xen maintainer - he is reviewing the material.
...but it would be interesting if we can come up with a bit more use-cases than the one mentioned in the presentation.

Gunnar: Agreed, I'd like to extend that question to all the HV vendors.  Please give your opinion at a later meeting (on where you might like to use the secure execution modes).

Franz: It's generally a good whitepaper.  I believe it is quite heavily downloaded also.

Gunnar: Please discuss with all your technical experts in the companies about useage of this, since when we start thinking of usage maybe the ideas we then have will impact the API standards work.

Gunnar:  I guess we have crypto listed in our table.  That's one, but maybe more.

Artem: Yes, and that is our position [...that cryptography should be implemented in trusted execution environment].  Specifically TEE, should run in the TrustZone mode(s).

Gunnar: Going through the table to see where we stand.  Are all topics being covered. 
...can we bring any to some final conclusion.

... vIOMMU. 

Dmitry: some code proposals but for various reasons it seems it will not make it into mainline Linux.  Performance is slow.  But there are no known use-cases in Automotive?

 ... CAN

Franz has linked a virtio-can driver

Anup:  This is the frontend driver.  I believe the backend was implemented in XVisor but was never sent upstream to me.

(more discussion)

Artem:  I think we found little need to virtualize.   Actual CAN access is typically implemented in another CPU.  Perhaps for sniffing / logging purposes [but that's so simple that you don't need a full stack]

Gunnar: Yes, I have also mostly seen designs where there is a separate Vehicle Interface Processor, or at least a separate core on SoC.

Artem / others:  The conclusion might be that there is little need to virtualize CAN.  USB might be similar but on the other hand it supports virtualization.

Gunnar: Sure and this might be the conclusion...  I can imagine some chapters [in a virtual platform specification] would just make this conclusion and perhaps point to some reference (in this case virtio-can) if someone feels the need to go beyond that.

Continued general discussion

Lars: We should pick one or two easy ones and not try to reach the answer for each.

Gunnar: Agree, .  I'm asking about them here but mostly it is the intention of going through the list, to see where we stand...  to find simpler ones to start with.

Anup: I think watchdog is important and also Random Number Generator.   Virtio has a proposal for  RNG but not watchdog.

Gunnar: We might discuss RNG under "crypto" but it's not the only usage so let's just add it separately.  Everyone, feel free to add to the list!

GPU...

Gunnar:  I think we need to get Matti and Nikola together to finalize discussion on the feasibility of 3D API standards.  For 2D everyone seemed to agree that VIRTIO should work.  For 3D, I think there are nuances we need to cover.  It's never all or nothing - we should be able to find some common parts (API and/or code).

9pfs...

Gunnar / Lars / other discussing.  It seems we can wrap it up with the conclusion that we don't see a strong use in Auto/Embedded.  Gunnar: I'd be fine with that - we should cover the most common systems.  I would write an initial "chapter" on this as an example.  But that's mostly a "negative" example [i.e. documenting that it is out of scope].   Now we need also find a positive one, which is needed and where the API standard is decided. 

Lars: (For Xen) we only needed it to support running containers.   I don't think it plays a part in server virtualization since there are so many other network protocols like NFS (and the VMs communicate between each other using those).  As soon as you set up networking, any network filesystem protocol works. 

Gunnar: My perception is that [in relation to virtio] this is from VM to hypervisor/host, and that only makes sense in Desktop - VirtualBox/VMWare Workstation, etc.  As a standard I imagined NFS would be too big/complicated (to use as API to/from a hypervisor)


AI: All participants asked to:

 1. Come to a (personal) proposal for your section and document this (is VIRTIO adequate, what else is needed, etc.  The process that is mentioned on working page
 2. If we feel uncertain, e.g. must have more use-cases, write that down.  What is required for you to reach the point of 1.

Gunnar adjourned the meeting with the idea that today's discussion was preparing us for getting this done (starting with one or two simple 


AI (Anup): Pick a topic to lead.  A free one, or you can also add to one that already has a name.


October 11, 2018 - Tech summit working session in Bangalore, with phone conference

October 9, 2018 - No phone conference because of tech summit

Tuesday October 2, 2018


Participants


Discussing the tech summit

The overall plan for working session is at:

HVWS Workshop Schedule at Bangalore Tech Summit

A few people asked for a more exact agenda...

The first hour (10.30 CEST, if we have calculated correctly)
will be on GPU sharing.


At 11.30 approximately, switch to Security Block with ARM leading. Up to
45 minutes ARM intro/presentation, followed by Q&A / discussion

After that, follow-up topics.

(later in meeting) Kai offered to prepare some presentation on block devices.

Bernhard: What will be the planned for conferencing?
Philippe/Gunnar: Zoom is our assumed default. If we need to change to Skype or Hangout we will let you know. Details will be sent by Philippe.

Bernhard: We would like to have more questions in advance to cover in presentation.

Gunnar: Collecting at the bottom of this page  - please add to it!

Artem: We could discuss my questions on implementation of OPTEE and support for virtualization ARMv8 and prior...


Virtual Platform Definition:

Crypto

Gunnar: Can we start HSM discussion by evaluating crypto support topic listed in table? Sang-Bum?
Sang-Bum: I have too many other engagements. I will be busy until 20th October at least. Maybe after that.


Block devices

Gunnar: We have discussed various aspect I'd like to bring down to some concrete results. Let's document it. Is VIRTIO good enough or what is the remaining gap?

Kai: Still investigating more
... but I think VIRTIO is not concrete enough. I think it needs more specialized descriptions
...That's why I want to investigate the TRIM command to see how well it works.

Kai: Persistence mgmt (stack) is not fully sorted out. (Not clear where in the software stack you should do what). What about Transaction/Commit
semantics for storage?  Should that (API) be defined?

Gunnar: Experience from XVisor?

Anup: XVisor provides the VIRTIO block device standard and that's about it. 
...It's up to each system to decide
... Where/when can dedicated memory per VM be used (pass-through), and where not?

Kai: For cost reason, one chip per VM is usually not realistic

Anup: Agreed.


General

Anup: The virtual platform specification, will it need to define the exact memory layout \[for memory-mapped devices\]? QEMU basically does this...

... some discussion
... conclusion that presumably yes this is needed if a VM is going to be fully portable? Let's return to this question.

Next meeting in 2 weeks, (with the Tech Summit working session in between).

September 25, 2018

Minutes TBD

September 18, 2018

Participants:

Apologies:

Agenda:


Minutes:


September 11, 2018

Participants:

Agenda:

Minutes

September 4, 2018

Participants:

Apologies:

Agenda:

Minutes

August 04, 2018

Participants:


August 28, 2018

Participants:

Apologies:

Agenda:

Minutes

August 14, 2018

Participants:

Apologies:

Agenda:


Minutes

Gunnar: Let's Re-introduce the VIRTIO/Device Driver/Virtual Platform definition project because of new/returning participants.

The intention is to write a virtual platform definition that can encompass the whole Automotive Industry.  So, supporting Linux & non-Linux operating systems (according to Industry
wishes). It would ideally support hypervisors developed with FOSS licenses and other models.

VIRTIO has been proposed as starting point. We're now evaluating each device type / topic:

- What is defined by VIRTIO
- What are the automotive Requirements
- Evaluate applicability and completeness. Clarify the gap.

Gunnar: First study has been on VIRTIO 1.0 but I have seen that there is
additional work ongoing. There is a git master...
Lars: Yes, a version 1.1 is planned. You should make sure to cover the
latest.
Gunnar: Agreed, action taken to steer our evalution towards git-repo master - if that's what is most appropriate?
Lars: I assume that's it, but I or George, could look into that.

George shares various experience from Xen project:
...VIRTIO was designed with KVM in mind first
...also for Xen we have found this to be a problem in some areas
...For example, it is assumed that QEMU (which provides the VIRTIO implementation when using KVM) has full access to all of the guest memory all the time.
...it is stated that VIRTIO devices bypass IOMMU completely.

George: In Xen we want to build features that do not match this, such as VM having control over which backends can write into its memory. We have a concept of Driver Domains, which adds security. A layer of security in case of bugs/vulnerability in implementation. For example something like a network card driver may be run in its own VM, with a well defined communication interface to the client VMs that use it.

Lars: Should we write down driver isolation as an automotive requirement?

Bernhard: Also, looking at the list of general considerations, please make sure to add Functional Safety

Artem: ... and Security

Artem: I see comments about implementation dependent things. Isn't the goal for GENIVI to implement standard implementations [that can be used by multiple parties?]

Gunnar: (paraphrased): Yes, this is a likely goal but it remains to be seen how this project progresses. We start with analyzing and defining requirements and specification. However, a specification needs implementation to prove
viability. This is GENIVI's experience since the beginning. Previous compliance programs, have always required _some_ software to prove for example an API specification is appropriate, before it becomes part of the specification.

Gunnar: For this project we have received input from, for example Green Hills, that [even independent of the question of porting VMs across different HVs], at implementation and quality maintenance of drivers is a
significant effort. So it seems many, including commercial HV vendors would benefit from more shared implementations too if it's feasible.

Nikola: Agreed. We will have to see [how much implementation can be shared] - such as... how much work is required to make VIRTIO implementation have high enough performance?

Comments From Nikola Velinov on the meeting notes: The shared implementation can serve as a a good reference for identifying the 'Virtual Platform' requirements on the actual virtualized device. It might not be the best approach to have the platform demand the usage of virtio. Rather it would be better if the 'Virtual Platform' defines requirements on the actual virtualized devices and points to the virtio standard as a reference of such in terms of the guest component. Performance for virtio in this case would not be as critical.

Bernard Rill: Have you [Xen Project] evaluated portability across architectures? ... I mean SW layers etc.

[ Discussion to understand how/if such standards are easy or hard to implement in diverse software. ]

Nikola: I would also agree. It is clear that VIRTIO came from a non-embedded starting point. Therefore need to figure out if it can be transformed towards better supporting embedded.

(... also some answer from Xen Project)

Gunnar: Interesting and important - please share such experiences by documenting/linking in the Wiki. We need to collect evidence and information to see the full picture. But I would like to steer the conversation back from "is this possible" more towards actually doing the required work now. (looking at table again)

Gunnar: Please volunteer for the topics that have no Champion yet.

Artem: Looking at Sensors... Aren't most sensors just providing an interface using some standard device class, such as serial? They rarely provide any particular HW support, so it's surely para-virt. So it is more
about defining a protocol. We have in fact defined some protocols, as part of XenPV work.

Gunnar: That might very well be the conclusion. Seems you have done half the work now (smile) - can you add these thoughts to the Wiki, and then we check consensus later? I'll put your name down on Sensors (wink)

Artem is assigned to Sensors. He also volunteers EPAM for media acceleration topic.

... Also what about "data-intensive devices". Fast DMA/memory implementation.

Gunnar: I don't know. I guess the IOMMU topic will branch out into a wide discussion (It's all about memory handling).

Lars: I can't volunteer me or George at this time - need to check availability.

Lars: I saw no info about mailing list...

Gunnar: At current we use genivi-projects.  Butt we can set up a dedicated list.  What would be the group desire - to have a smaller list for intense discussion in the core group?   Because I thin to keep others informed, it would just be yet another list for them to subscribe to.

Lars: Genivi-projects should be OK.  It won't be too high volume.

Gunnar: OK, I will add clearer info to project page.

Lars: We might be interested in smaller focused meetings around some topics, bringing together for example Matti, George and perhaps Stefano.
Gunnar: No problem, we just arrange the meeting time for particular meetings.
Lars: OK, I will use the mailing list.

Lars: I think (VIRTIO) v1.1 has a deadline close to end of the year. We should check the window of opportunity to affect it.

Sriram: I have joined. I will study the Wiki page and VIRTIO specifications.

Lars: ...will be busy for the next 3 weeks or so. Open Source Summit and other things.

Summary of meeting and housekeeping.
Meeting adjourned.


August 7, 2018

Cancelled due to vacations

July 31, 2018

Agenda:

July 24, 2018

Agenda:

July 17, 2018

Apologies:

Minutes

July 03, 2018

Participants:

Agenda

Minutes

Text below taken from the newsletter:


  GENIVI Announces Schedule for Fall Technical Summit in India

Many will remember that in 2018, GENIVI moved from a two member meeting per 
year model to a single, large member meeting in the spring and 1-2 more 
regional technical summits in the fall.  The details for one of those 
summits are nearing completion and GENIVI wants to get this important event 
into your calendars immediately.

On 10-11 October, GENIVI will hold a technical summit in Bangalore, India. 
The summit will expand on two active projects within the vehicle domain 
interaction strategy, notably Graphics Sharing and Hypervisors.  The agenda 
will be finalized during coming weeks; however, GENIVI has in mind three 
primary goals:

     * Provide an overview of the GENIVI Alliance, its projects, and recent 
deliverables, to an audience that may have not been able to attend recent 
member meetings
     * To inform and engage a technical audience in the work of our domain 
interaction projects starting with Distributed Graphics and Hypervisors
     * To equip developers with hands-on experience using APIs, reference 
code and supporting documentation so that they can produce software that 
delivers solutions needed for domain interaction challenges.

The summit will be held at the Sheraton Grand Hotel at Brigade Gateway and 
will begin at 9:00 am on 10 October and end at 4:00 pm on 11 October.  A 
networking reception will be held at the end of the first day. 
Registration for the event will open on 1 August.

Please consider attending this important technical event and should your 
organization be interested in sponsoring the event, please contact Karin 
Hanson, GENIVI Event Manager for more information on opportunities available

virtio

Process improvement



Planned absences

26-7/13/08 christoph
24/7-31/7 nikola not available, same for 7/8 TBC
end of September - sang bum
15/7-21/7 Guru
absence a few weeks, probably some time in July-Aug Gunnar
9/7-13/7 & 1/8-15/8 Philippe
no upcoming holiday before mid-October Matti

June 26, 2018

Participants:

Minutes

Sriram's notes - minor edits and formatting

(Camera use-case an architecture)

June 19, 2018

Agenda:

Participants:

Apologies:


Minutes

June 12, 2018

Agenda:

Participants:

Apologies:

Minutes

June 5, 2018

Agenda:

Participants:

apologies: Matti (Opensynergy)

Minutes

May 29, 2018

Agenda:

Participants:

Minutes

review of the summary of AGL paper prepared by Nikola
summary is short, everybody invited to read it
sections 3, 5 & 6 are the most relevant for HV project
section 3 can be adopted as a set of reference use cases
discussion on how we (as a GENIVI project) can build on the inputs from the AGL paper
Certain chapter should be reusable as they are, others with some modification.  Some chapters ahave useful content which should be quite widely applicable (multiple Linux, Yocto-based systems etc.) but the text cannot be used as-is since it uses a lot of specific language referring to "the AGL system", and similar expressions.

next week

May 22, 2018

Participants:

Apologies


Minutes

API standardization
Matti started writing down thoughts.  Needs some approval on content

Matti introducing:

Discussion:

Additional thoughts from participants.

Wrapping up

Action Items

May 15, 2018

No posted minutes


May 8, 2018

Minutes


Discussion on – see the title Device Standardization on main page: Hypervisor Project

Sang-Bum:  Hypervisors need to include a mandatory access control features
Matti: But in theory guests can run without ever speaking to a hypervisor.
Matti: It is difficult to standardize APIs to speak to the hypervisor itself - easier to standardize device driver layer.

Sang-Bum: We need to add a security architecture to control (negative) impact from one guest to another.  We need MAC support APIs to achieve that.

Matti: I would like to start the standardization topic by writing down a proposal.l

April 19, 2018
(Full-day All Member Meeting Workshop)

Please see the Hypervisor Workshop Schedule at Munich AMM page for schedule, speakers, participants and meeting minutes.

April 10, 2018

Further preparations of AMM agenda

April 3, 2018

Participants

Apologies

Minutes

March 27, 2018

Participants

Apologies

Minutes

March 20, 2018

Participants

Philippe Robin (GENIVI)
Sang-bum Suh (Perseus)
Matti Möll (Opensynergy)
jithin (TataElxsi)
Gunnar Andersson (GENIVI)
Christian Schulenberg (BMW)
Subramanian (Alpine)
Gayathri PP (Tata Elxsi)
Stephen Lawrence (Renesas)
Ajmal  (Tata Elxsi)

Minutes

March 12, 2018

Participants
Philippe Robin (GENIVI)
Gunnar Andersson (GENIVI)
Sang-bum Suh (Perseus)
Christian Schulenberg (BMW)
Horst Saier (Mentor)
Subramanian (Alpine)
Guru (Bosch)

Minutes

Gunnar highlighted some of the topics for the workshop listed under Hypervisor Project.

Sang bum: introduced the workshop to LGe, Hyundai and Access in the recently hold Korea REG F2F, would like to collect their opinion so that we can share at the workshop
trying to contact xen so that they give a presentation at the workshop on their automotive projects, intends to contact redhat with is leading virtio
Sang bum: contact with car oem and tiers 1, my personal opinion is they do not know yet what it is the exact case to usefully apply HVs to a vehicle, in the process of trying to convince car OEMs to deliver market scenarios, coins the idea of sending a questionnaire to car oems
Sang bum will share an initial questionnaire with us at the next meeting (20 March)
Horst: my interest lies rather in graphics sharing
Gunnar:graphics will be one of the topics of the workshop
Horst: how to share graphic buffers, is a solution available in the open ? it is currently very silicon vendor dependent
Gunnar: Horst Saier can you a short intro in the workshop about it ?
Gunnar: @sang bum: are you familiar with gpu sharing ?
Sang bum: yes, I am very familiar, the problem is that silicon vendors except Intel do not publish the code of the drivers for gpu sharing
short discussion on audio virtualization
Sang-bum: would like to discuss device driver architecture at the workshop
Sang-bum: will propose a list of topics for Wed 14 March EOB
Christian: we are very interested in the market survey and what is available from vendors

March 6, 2018

Participants


Minutes

We simply discussed and filled in the topics under Hypervisor Project.  Discussion much driven by Albert and Christoph.

February 27, 2018

Participants

Minutes





an white paper released by Arm which gives and insight into the architectural updates in Armv8.4 in the Trustzone:
https://community.arm.com/processors/b/blog/posts/architecting-more-secure-world-with-isolation-and-virtualization