Page History

...

Minute takers according to this page 

July 12, 2021

Participants:

• Stephen (Renesas)
• Adam (Kernkonzept)
• Matti (Opensynergy)
• Gunnar (GENIVI)
• Oleksandr (EPAM)
• Kai (EB)

Minutes

• Gunnar: I met with Arm (Bernhard) and Francois Ozog (active in Linaro).  We discussed virtual platform specification, if there are additional automotive-specific hardware that need VIRTIO support (e.g. do we have a proposal for FM tuner? (No, not currently))

Discussion on the usage of virtual platforms as a hardware-portability solution:

• Gunnar: We see this trend.  I'd like to analyze this idea further, compared to for example just making stable user-space APIs and creating new kernel drivers for new hardware. 
  • => Is this not just shifting portability work "somewhere else". 
  • Let's analyze how "virtual platform API is stable" is different from "user-space API is stable" (i.e. just port drivers to new hardware..)
• Adam: BSPs that add a lot of patches to Linux get stuck on older versions.  Not using mainline.  Updating to new kernel drivers difficult (N.B. officially no APIs are stable inside Linux kernel)
• Matti: Linux kernel in particular, is an operating system kernel and a hardware-abstraction at the same time, which is challenging.
  
  • Future challenges: Value-add for SoCs could be difficult if the [hardware abstraction] API is limiting.

• The virtual platform / VIRTIO / Trout and others.  It seems the "new" distinction is a clear focus on a hardware-abstraction layer?
  • (partly agreed, discussed the existence of firmware as one abstraction already used, and on PC side the hardware it self was standardized, etc.   Overall, a complex reality)

• Summary:
  • Kernel updates are driven by fast development, security issues, etc. 
  • Fast changes, no internal API stability guarantee etc. = updating drivers is a major issue.
  • It seems this situation can't be avoided, and the industry is looking for a solution to the challenge.  
  • The theory seems to be that keeping API stable and efficiently port to new hardware, could be more feasible to do in the virtual platform.

• Discussion turned to evaluating the effort (that the industry is also considering) to create new kernel(s) instead, as a Linux alternative (for safety, and development concerns as shown above). 
  E.g. if they have a POSIX API, is that "enough".  => No... could still be a large effort to port existing functionality.
  • Gunnar: As an example, consider systemd which early on used Linux-only APIs.  And then a lot of functionality built on systemd.  Such examples makes porting software a challenge.
• Also discussed how large part of Linux' functionality is actually used in practice in the industry?
• Matti:  (Explicit example that shows the current situation)

  • io_uring recently added to Linux.  It accelerates applications a lot.  A hardware vendor that is able to use these latest features could have an advantage (hardware itself not faster, but the software runs faster).  

  • => With a virtual platform abstraction, updating to a new kernel with the new features should be feasible.

June 2021

• Regular meetings held every week.  No specific meeting minutes written.  Results in AVPS and topic planning (link below)
• AVPS v2.0 release.
• Working on deep-dive topic planning

December 14 2020 → May 2021

• Regular meetings held every week and results tracked in AVPS document and JIRA tickets.

December 7

• Participants: Stephen, Gunnar, Dmitry, Adam, Peter

• GPIO - clarified misunderstanding that referenced SCMI even though SCMI does not cover GPIO.   Closed open issues and finalized requirements.  Chapter will be done, after final polishing.
• Initial discussion on the structure of final GPU chapter (bringing together all input from previous hardware studies)
  • We might need a plausible product design scenario to support the inclusion of VIRTIO-GPU / VirGL based requirements.  Also consider how to handle a non-Linux OS, if that is included in the scenario.
    Most other requirements will lean on hardware virtualization support, but the group did not want to lose the idea of support simpler hardware too.
• Dmitry has done some updates on Camera/Media – postpone discussion to next time.

November 30

     FOCUS : GPU virtualization – Features of the PowerVR/Imagination GPUs (used in Renesas R-Car SoCs).
      - Presentation from Thomas Bruss, Renesas.

    - Discussing the opportunity for a common "model" of modern GPUs that can be the basis for shared requirements in the virtual platform standard.

November 16 - 23

Discussions captured in JIRA tickets and in the document.

November 9

Minutes pending

...

Participation planning:

• October 19 - GPU focus?  Discussion of new Mali features?
  •  Bernhard + Arm colleagues, wants to present Mali GPU
  • Adam 
  •  Dmitry still vacation            
  •  Oleksandr - vacation?
  • Daniel Stone?  Emailed last week.  Send calendar invite also.       
  • Eugen - Emailed
  •  Stephen likely interested
  •  Ozgur - Emailed              
  •  Peter
     
• October 26 No meeting (AMM week)
• November 2  
  • Adam
  •  Oleksandr
  • Dmitry
  • Peter ...
• November 9   Adam   Oleksandr  Dmitry Peter ...
• November 16 Adam   Oleksandr  Dmitry Peter ...
• November 23 Adam   Oleksandr  Dmitry Peter ...

October 12

• Dmitry vacation,  Adam has a conflict this week only
•  Oleksandr
•  Stephen join if possible (ad-hoc)
•  Peter

October 5

Participants:
Adam Stephen Dmitry busy  Peter busy  Oleksandr busy Bernhard tried joining (missed by Gunnar)

...

August 31 - September 28

• Another 1-2 discussions on Graphics
• Continued discussion and work on the specification – results are in working document and in JIRA.

Participants:

• Primarily Adam, Dmitry, Oleksander and Kai.  Occasionally Bernhard. For graphics also Eugen.  Peter had vacation.

August 24

Participants:

• Peter (BMW)
• Daniel Stone (Collabora)
• Adam (Kernkonzept)
• Gunnar (GENIVI)
• Dmitry (OpenSynergy)

Apologies:

• Adam noted he has a conflicting meeting this week
• Oleksandr / EPAM colleagues – there is a public holiday

Minutes

• Producing the generic model of future GPUs.  Adam started writing inside the AVPS as a place to hold the information for now.
  Daniel can view and contribute.
• Gunnar: That's fine for now.  We should work on cleaning up the AVPS for release in the months to come.
• Bernhard:  Next generation is fairly fixed but a wish list is useful.
• Peter: It is very valuable to know how Arm engineers think about this.  We can discuss common parts of future designs 
  Gunnar: ... even if Silicon Vendors have their own unique details and/or use some other GPU cores.

Switching to discuss AVPS planning and open JIRA tickets.   

Gunnar: A least the "Evaluate Status" column is getting fairly empty.  This is good.  There are some big ones there still, e.g. DSP/TSP.

• We discussed DSPs primarily.   - see notes in JIRA ticket.  

  Jira
  server JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key HV-17

• Gunnar: There is a lot to sort out here
  • 1. Technical organization (like defining the potential software/hardware stack, similar to the GPU discussion) 
  • 2. ...and as far as the technology is still unclear - understand current project organization (how are projects solving this today, what conversations need to be had between product owner (e.g. OEM), Hypervisor implementor, and the silicon vendor?) 
    The idea like for any hardware chapter in AVPS, is at mininimum,  to try to have a few of those conversations proactively, so that there is a better basis to start from when going into a production project, and as far as possible, create some generic solutions/standards that remove obstacles.

August 17

Apologies:

• Dmitry

Participants:

• Peter, Adam, Oleksandr, Gunnar

Graphics discussion not fully successful today due to missing key participants, but we collected the thoughts of those who were here.

Graphics

Let's recap our thoughts and conclusions from last week's discussion

Adam: I have always thought you need hardware support to do this properly.  But of course if you are already in another  situation you might have to do something different.
But [the hardware-assisted solutions] involve NDAs and binary blobs (that are more difficult to analyze generally).

Peter: We discussed some similarities and a working model last week, the idea of the command queues that seems to be similar in future solutions.  There are some special support for video and others.   I would like to achieve this model that can progress this without being too specific on one solution.  It may also avoid NDA issues.  Find these common abstractions to work on.  Multiple hardware should be able to be mapped into this.

Peter: We need to consider about composing images also - the display output (2D).  When this is combined with other video feeds, there are safety concerns that need solutions.

Gunnar: There are some patterns for handling safety (e.g. fallback to simpler HMI if the advanced one is fails (recognizing failure in various ways)), and these patterns may drive our standardization approach.

Peter: These patterns are useful.  Also considering that there are different needs - not all platforms require ASIL-B, for example.

Oleksandr: I'm not as focused on the graphics subsystem, so it's hard to say that much and what we are doing concretely is covered by NDAs.  We have experience with hardware that has hardware-assistend virtualization support and we are implementing such things in Xen.

Some hardware has implemented more than one GPU and can use simple pass-through of each of these to for example 2 VMs.

Gunnar:  Discussion last week with Daniel and others led to the conclusion we should start this "general model" discussion with the implementers of future graphics hardware.  I feel like we need to produce a description that we can bring with us to start that conversation.

Adam:  I would like to give it a try.  (This week)

Gunnar: Great, and then Peter may want to add to this.

Power Management

Oleksandr:  I have made some proposed edits.  SCPI should be deprecated because it is now covered in SCMI and we should require the 2.0 version of SCMI.

IOMMU

Oleksandr shares some experience from Xen implementation. 
Further discussion how to bring the chapter to a close, in particular the 2-stage IOMMU question that is still not brought to full conclusion.

...

August 10 – Graphics/GPU focus

Participants

• Daniel Stone, Ozgur Bulkan, Adam, Dmitry, Peter, Gunnar, Oleksandr, ... ? (I missed recording the full list)

Gunnar introduced the AVPS goals a bit and mentioned that in some hardware areas (and almost surely for GPU), the AVPS specification can/should not reach the point where it requires only one way of doing things.  It can still be useful to dig deeper into a few things, and then describe a few different choices through optional or conditional requirements.  It is still much more useful to have that analysis done when a production project starts than to have a blank page.

Daniel: Requiring Vulkan would make sense but will not be supported everywhere so unfortunately it cannot be the only choice.   GL API is stable.

Peter: [We need to discuss]  technology roadmap for next generation GPUs (HW support for virtualization)

Daniel:
ARM, Renesas, Qualcomm, others would need to discuss this to get the information, but everything might not be shared.

...HV vendors implement this when the technology is ready (NDAs)

Every VM has it’s own virtualized GPU. Dedicated command queue per VM.  Buffer handling can be challenging (sec/safety, etc.)   It gives you a “direct access” to the hardware.  Normal drivers and software can be used, because it looks like a GPU.

Peter:  Can a standard model for GPU be defined which can help development (of specification and code/solutions)?  Command queue is common for all.

Daniel:  Concentrating on the API definition which can be generic, and over time hardware support could make the implementation of it easier.  This is the VIRTIO queue API level.

Ozgur: What about the original VIRTIO-GPU 3D specification

Daniel: It is similar to VirGL but was not quite the same.

Discussion would be needed with the real graphics engineers (within ARM, Imagination, Qualcomm….) to see if they are open to discuss standard APIs in one level.

Ozgur: Vulkan path is yet another choice?

Daniel: Conceptually similar.  Host/HV would still need to manage resources, track all the Vulkan objects, buffers, textures, targets.  This is the same for virtualization of Vulkan and OpenGL.

Ozgur: SoC providers do not want to rewrite their implementation (e.g. to support VIRTIO queues [or other standard virtualization API]  Basically they provide everything from user space APIs to the hardware…
...

Daniel: Yes, I agree.  Hardware independent and hardware dependent APIs will likely be different APIs.  We can (only) expect a few basic things about HW dependent (using channels/queues and buffer handling).

Ozgur: VIRTIO is only concerned with multi client rendering?
Daniel: Yes, it does not handle multi leases and other more complex situations.

Ozgur: Can we start thinking about things like nested compositors?
Daniel: DRM/KMS provides some capability for HW compositors but not the constraints you need (to match the (virtual) hardware capabilities).

Ozgur:  Will it need kernel/driver changes?
Daniel: It’s primarily the API side for virtualization.

Daniel: Way forward.  Split the problem.
1. Write how we think a fully hardware specific path will work. (a generic model for how w e think HW assisted virtualization is done)
2. The fully generic VirGL / vulkan path.  We can start encoding more specific requirements.

Ozgur: What can be implemented to test this now?
Daniel: VirGL already works on top of any OpenGL (GLES) implementation.  Mesa, and also others.

Way forward

Daniel: I’m happy to encode the requirements that we have already today in VirGL.  Over time I can try to do the same for the Vulkan path.   For the HW specific approach, can we reach out to the platform vendors?  or HV implementing companies that are likely implementing some of these things now [with the latest hardwares].

Gunnar asks Dmitry to see if there is a way to have a (private) conversation with potentially ongoing commercial implementation projects, to draw the boundaries between what could drive the specification content (and what could not).

Peter: The model approach is very good because we would then be less dependent on the hardware vendor proprietary information while this is being built out.

Gunnar mentions that ongoing work should be complementary and can together improve the situation, from specification side, and from trying out implementations on AGL and other projects.  The AVPS work provides the API specification, ensures multi-OS aspect is not lost, and aims to influence AUTOSAR and other industry initiatives to align on a common way forward [based on the open development of AVPS].

Daniel: It would be useful to get Panasonic’s input since they drive a lot of implementation in AGL for virtualization.

Gunnar:  Yes.  Both the implementation and AVPS is VIRTIO focused which should help compatibility.

July 20

Participants

• Dmitry
• Adam
• Oleksandr
• Kai
• Gunnar

Introduction to Oleksandr (EPAM), working on VIRTIO support in Xen.  He has lately worked specifically on implementation on IOMMU on Renesas platforms.

Discussed again how to rewrite Camera + IOMMU from scratch with all the new information we have gathered
(It is currently disorganized, but has a lot of good knowledge). 

Actions for Dmitry and Adam to do this rewrite.

Gunnar on vacation next week.  Do you want Philippe to open the call?
Adam: I will work on the chapter, I don't need the phone call for that.

=> Next week will be skipped.

Absence planning
See July 6 and 

+ Gunnar, away (this week) and next, and probably again end of August (1 week)
+ Kai - mid August 17 August → 6 September
+ Oleksandr - possibly starting last week of August → 2 weeks

Kai found an interesting paper from Strategy Analytics.  Plan discussion about it later on.

July 13

Additional work on Camera and IOMMU with Dmitry and Adam - results in document.
AI: (Media and Cameras) Gunnar to work on combining original and new text to more logical flow.
AI: (Media and Cameras) Dmitry to also review red text in the same chapter

Info: Let's plan for Graphics oriented meeting some time in the future, inviting Daniel Stone.
Be aware of presentation that Daniel also posted to the GPU related Wiki page.

Info: Gunnar likely to have vacation some time after next week's meeting.

July 6

In-depth review and improvement of Cameras chapter → results are in the working doc.
EPAM colleagues missing, will follow up those topics next week.

Vacation planning

Peter - No vacation until Mid September
Dmitry - same for me, probably October at the earliest.
Adam - similar, nothing planned at the moment...
Gunnar - end of July / beginning August.  Will specify better soon.

June 29

Apologies from Artem + colleagues (public holiday), Peter (unexpected mgmt escalation), Adam, etc.
Have no info from Dmitry or Matti about attendance today.  Also not from Kai.
Other participants (Matt, Bernhard) are more attending on-demand / occasionally and were not expected today. 

=> Meeting is skipped.

June 22

AVPS v2 work:

Continue discussing with Artem and Adam on IOMMU including programmability from guest, and requirements for coprocessors.  We are getting there.  Adam will try to rewrite once more.

Artem: I am sending over details that might be interesting, about the implementation for co-processors on Xen:

• Co-processor_management_under_xen.pdf (XenProject website)
• XPDDS 17 keynote Shared Coprocessor Framework on ARM (Slideshare.net)
  
  

Went through comments and minor changes in the whole document and accepted all minor changes.  Open points kept for discussion with a few others.

Need time to discuss with Dmitry on changes in Media chapter and more.

Artem: I intend to involve 2 new colleagues into this work.

April 27 - June 15

Meetings held as usual, except for some bank holiday.

Minutes have not been recorded separately.  Instead, discussions and updates on the Automotive Virtual Platform Specification have been recorded directly in the working document as text and comments.  The JIRA Tracker is also used to track updates and assign tasks.

April 20

Participants

• Bernhard Rill
• Adam Lackorzynski
• Dmitry Sepp
• Matti Möll
• Gunnar
• Alex Agizim (EPAM)
• Kai Lampka

Apologies

• Peter (Zoom was blocked?)

Minutes

Went through tickets.

Discussed development support ticket → DLT discussed at some length.  Various "known" discussion points (ID uniqueness, on-disk storage format, common timestamp references) but they become more relevant in a Hypervisor setup.

Kai reviewed Booting chapter and found a few issues/unclear direction.  Moved chapter to "Improve" column.

April 13 – no meeting (Easter Monday)

April 6

Minutes pending

March 30

Participants

• Bernhard Rill
• Peter
• Adam Lackorzynski
• Dmitry Sepp
• Matti Möll
• Gunnar

Apologies

• Artem (conflicting meeting)

Minutes

• Peter:  Defining the platform better.  The Arm specification on secure partitioning can also be useful to look at.
  • This also includes use-cases, to better define...
• Bernhard: Yes, and a few other specifications might be useful also.  Others are not so applicable.  I can look at this.
• Peter: Starting with VM scheduling, for example.
  • Matti: We can only define the interface...  what other "surfaces" might be described?
  • Peter: Just thinking that going from the top we realise VMs need to be scheduled....   Example - Android + RTOS, how is switching done and what does it lead to?
    • Gunnar: This goes into a kind of system design.  If you are speaking about cores etc.
• Bernhard: Two prominent examples of interfaces...
• Matti: Define what is a platform in general, and is it focused on components or interfaces?
  • A platform allows things to be built on top of it.  It cannot be too hard to implement, because then it will not be implemented to the degree that it becomes really usable.
  • Think about the right level.  Not too complicated.  Not narrowing the solution space too much. And not too broad so that portability is not achieved.
• Peter: We are quite well defined here.  Starting from defining a... hypervisor based platform
• Matti: If it is an automatic (preemptive) scheduler, it cannot be defined using interfaces.
• Gunnar: You can set priorities.  Not from the VM, but when configuring the platform.  (Therefore the AVPS could set requirements on it).
• Peter: We can still write requirements for this.  The behavior can be defined.
• Peter: Variants of the platform advanced/basic could be an example.
• Matti: Currently covered in AVPS by "If the platform includes feature X, then it must..."

Short review (on overtime) of the AVPS v2 ticket priorities.

March 24

Whitepaper work and AVPS prioritization

Minutes pending

March 16

Whitepaper work and AVPS prioritization

Minutes pending

March 9

Participants:

• Dmitry
• Kai
• Adam
• Peter
• Michael
• Gunnar
• Philippe

Minutes

Gunnar Presented Webinar-Report draft.  Purpose and content.  Recommended reading for all, but especially those who did not attend.

AMM plans:   GENIVI All-Member Meeting planned for May 12-14 in Leipzig, Germany

AI (all):  Block 12-14 May (+ possible travel time) in your calendars.

• Philippe:  Make sure to separate content preparation from any concerns about virus outbreak. 
• The conference is planned to be F2F as of now.  In any case we do not stop our preparation since content is reusable.  Evaluation of the situation of course continues in parallel.
  Preliminary attendance possibility:
  • Kai - Not travelling – family plans
  • Adam - OK.  Leipzig is near.
  • Dmitry - OK.
  • Peter - OK, most likely, company will clarify attendance and likely to come, also bringing other colleagues.

Discussing the comments given in whitepaper editable document, and many general discussions about the direction and content.

• Possibly split into more than one document.   Why Virtualization in general vs. deep dive into technical decriptions.
• or split one document into two sections
• Need more structure, more headings, more sub-chapters, more summary and leading the reader from intro to details.

AI (all):  Get your (Google) account connected to the document, with edit capability AND everyone expected to give some input until next time.

March 2

Participants:

• Artem
• Peter
• Gunnar
• Philippe

Minutes

• Xen project status & current state from Artem
• Walkthrough AVPS 2.0 prioritization tickets
• Lots of discussions on plans / purpose / and various input to the Hypervisor Project overall – initiated by Peter, filled in by Artem.

February 17, 21, 28

Minutes pending

February 10

Participants:

• Kai
• Dmitry
• Adam
• Gunnar

Whitepaper:

• Main subject as agreed: "Why is Virtualization needed?"

• But should we also include challenges that are added as a result of choosing virtualization?
  For example shared-memory as discussed in the comment by Michael on Whitepaper - first private draft text

Discussing shared memory challenges:

Locking implies timing interference.  Lock-free implementations are complex but important.  Can hardware support be provided to improve the implementation of shared memory implementation?

Kai: You would sacrifice isolation if different criticality functions access the same memory.

Adam: For video the approach be fine as long if data corruption is less of a concern.  Depends on the use cases of course.

For sharing it is required to consider hardware support for making some access read-only to guarantee that non-critical software cannot change the memory values of critical software.

Gunnar:  What about if there is only one writer (critical task) and multiple readers.  Can non-critical readers negatively affect critical software by starving the memory bandwidth or similar?

Adam: Generally starving is not possible due to hardware setup.  A worst case analysis would be needed.

Adam: Hardware counters usually exist that can enforce budgets on the memory usage.  Usually two counters or so, the number of counters might not be enough.

Kai: How do the lock-free implementations perform in worst-case situations?

Dmitry, Kai:  Locking (handling multiple writers or handling that writing is complete before reading starts) is orthogonal to the performance issue.

Gunnar: One detail, don't forget buffer sealing (as Linux calls it).  It is a security feature (needed for some use cases) to set a buffer read-only as it is being handed over.  This is to be able to guarantee that a writer does not modify the buffer again, after  it has been handed over to the reader(s).  Such late modification could be used by a malicious writer to exploit bugs in the reader implementation.

Conclusion:  Yes, it might be useful to include, in the white paper, some challenges topics and how to solve them (e.g. shared memory).

Gunnar to send out links to webinar.  Participants invite their colleagues.

Weekly meeting, February 3, 2020

Minutes 

• We went through the slides for upcoming webinar.  Feedback on content.

Weekly meeting, February 27, 2020

No minutes

Weekly meeting, January 20, 2019

Restart after new-year, CES, etc.
Spec has been released.  Dissemination/information given to various automotive industry individuals during CES.

Matti is away from project for a while.

New JIRA items, one per "chapter" to track which parts need update.

Some additional edits will be done by OpenSynergy tech-writer (Susan)

Action to all:  Each participant finds at least one colleague/friend to show specification to for feedback.

Webinar is being planned beginning of February.

Artem:  For Xen we are quite busy atm, working on safety certification, some ELISA project participation, and of course virtio implementation...

No progress on whitepaper - need leadership to assign tasks/chapters in practice.

Weekly meeting, December 9, 2019

Rough minutes: Went through spec from the last page in reverse.  Discussed open points. 
Actions taken by Adam to update 

Weekly meeting, week of December 2, 2019

Participants

• Gunnar Andersson
• Eugen Friedrich, ADIT
• Michael Doering,  Bosch
• Artem Mygaiev (until 10:45)
• Kai Lampka
• Adam Lackorzynski
• Matti Moell
• Philippe Robin (part)

Apologies/Absent

• Michele
• Dmitry

Agenda

• Memory/buffer sharing standards for graphics applications (with Eugen Friedrich)
• AVPS completion work

Discussing graphics/memory buffer sharing.

libvirgilenderer implements the API, including reference implementation of VULKAN API
In practice there will be only one implementation.  It might make sense to require using libvirgilrenderer quite simply.

The driver is part of MESA project. 
Non-virtual operating systems?   QNX apparently ported both driver & renderer part.
Integrity?    MESA driver is a user space library - creates a command stream - should be easily portable (paravirtualization assumed).

Eugen: There was a proprietary API for memory sharing proposed in...
...Other APIs just give you a handle, and you don’t really control what happens below.
...Should there be a defined way how memory can be represented in a generic way?
Matti: VIRTIO basically is this in fact.   The scatter-gather lists are providing this.  Managing the lifecycle of the buffers is the challenge.    Gerd Hoffman / RedHat has proposed a standard - see virtio list. (https://lists.oasis-open.org/archives/virtio-dev/201911/msg00149.html)

Need to build in handling of the particular characteristics of the hardware.  E.g. special alignment or size restrictions. Usually VIRTIO has per-device handling today (GPU, block-device, … ) because of this. 

Intel created a proposal to require host to allocate and give to the guest.  Memory accounting troubles follow. This was not accepted in the community.  

recent proposal VIRTIO-GPU resource attachment.  patches to qemu to get a DMA buffer from a guest target buffer.   udma (in qemu). This could be applied to embedded HVs.

create_memfd - filedescriptor.  udma driver - ioctls to control it.   See DMAbuf in Linux source. drivers/dmabuf/udmabuf.  Note memfds are not part of POSIX standard.

Gunnar: These are Linux specific APIs then. Any different consideration for non-Linux OS (in a virtualization environment).

Matti: Should even be easier to implement in simpler OSes (since user space code may be more privileged to access the details).

Matti: One answer is that the GPU 2D specification already allows sharing buffers.  You have to keep into account some details about the memory model of the HV.  
VMs can tell the HV environment about buffers they would like to show, including giving this buffer to another VM.

Some kind of global compositor and it is given the buffers, e.g. that compositor might be within one VM, but it could be a hardware display device...

How to handle the lifecycle of the buffers?

Matti: VIRTIO specifies a low level way to communicate between VMs with virtqueues.  The other is the description of the device implementation.  How to handle the scatter gather lists of buffers.

Gunnar: The discussion involves different standards, in addition to standard Linux/Wayland, there is for example the Android graphics stack, potentially others...

Wayland can display a DMA-buf so if only you can get a handle to that, it's one way.

AVPS completion work

• Went through more comments.  Some parts have been proposed as resolved after rewriting the section (Gunnar)
• Matti Technical writer input, can the document be freely changed?
• Agreed to welcome technical writer changes, but with some track-changes capability so we can see if any part was changed in a way that makes it misleading.
• Gunnar:  ...it sometimes happens when unclear explanations are clarified that they end up to say the wrong thing instead.

...

Weekly meeting, week of November 18, 2019

• Stephen Lawrence, Renesas
• Gaurav Sinha (Micron)
• Michael Doering,  Bosch
• Adam Lackorzynski
• Dmitry Sepp
• Philippe Robin (part)
• Gunnar Andersson

Minutes

Intro and discussion with Gaurav.   AVPS work - documented in the google doc itself.

...

Weekly meeting, week of November 18, 2019

Participants

• Artem Mygaiev (part)
• Gunnar Andersson
• Michael Doering,  Bosch
• Kai Lampka

Apologies/Absent

• Michele
• OpenSynergy x 2
• Adam

Minutes

• Introduction Michael Doering, Bosch
  • Proficiency in networking especially TSN, and other things
• Introduction of work, purpose, results for new participant Michael
• Haven't heard from OpenSynergy this week.  GA will follow up.
• Artem:  Note recent feature list for Android R – VIRTIO mentioned.  Follow-up with Google.
• Gunnar:  Yes, following up on HV standardization is a good idea when we discuss Android-SIG activities with Google
• Showing comments in draft document from Michele
• Power management text under Hardware considerations sparked discussion on if we have concluded the situation for Power Managment feature requirements.  Actual chapter is not written? 
• Michael will read through whole document and get familiar with the work in general
  • Possibility to pick any chapter and improve it.
  • Gunnar: We appreciate input on TSN but it is not critical for first draft so focus might be elsewhere first 
• Kai has limited time next week/weeks due to teaching obligations, as well as planned personal training

Weekly meeting, week of November 11, 2019

Cancelled due to Tech Summit.  Not everyone was aware though.

Weekly meeting, week of November 4, 2019

Participants

• Artem Mygaiev
• Michele Paolino
• Philippe Robin
• Dmitry Sepp
• Gunnar Andersson

Apologies

• Matti Möll (office guests)
• Kai Lampka (other obligations)
• Adam Lackorzynski (other obligations)

Minutes:

• Working on draft spec.  Most discussion was on IOMMU with requested input from Artem 
• Michele to look over web pages, project introduction, and Google Doc (editing, commenting...).  Consider hardware specifics and ensuring t
• Artem to look over draft spec, perhaps mostly IOMMU.  Focus on narrowing spec into a draft release.

Weekly meeting, week of October 27, 2019

Weekly meeting, week of October 20, 2019

Weekly meeting, week of October 14, 2019

New meeting time used today, Monday 10:00 CEST

Participants

• Adam Lackorzynski
• Artem Mygaiev
• Matti Möll
• Jens Uwe Schaefer
• Kai Lampka
• Michele Paolino
• Gunnar Andersson

Minutes

• Introduction and welcome to new participants
• Review current work topics and purpose with new participants
• We went through the status of the the Virtual Platform definition work, updating the table and some few changes in spec text

Weekly meeting, week of October 9, 2019

Meeting missed/skipped due to ongoing rescheduling

Weekly meeting, (next meeting ) October 1, 2019

Participants

...

• Lots of topics (5 presentations), lots of discussion
• Little time for Q&A on each - basically every topic needs deeper investigation and discussions
• See presentations

May 14 - cancelled due to AMM

...