...
-
IPC and Inter-Chip Communication- Communication between different guests or hardware parts. Does it affect the Virtual Platform or is it just run transparently on virtual socket?
- One specific use case is inter-cpu communication. Particularly in the case of converged SoCs, e.g. comms between app on RT and general purpose CPU.
- Are there standard choices? Are there many vendor-specific proposals, like IC-COM? (Is that an AUTOSAR standard?)
RPMSG → https://www.kernel.org/doc/html/latest/staging/rpmsg.html
NXP has some framework? - MCAL is intended to be abstraction layer for the actual communication choice?
- ... but it still need to be implemented, (so actual choices matter at some level)
- There are non-AUTOSAR implementations as well.
- Impact and design of security.
- Hypervisors using inter-chip communication somehow?
- Example (Xen): HV controlling MFIS (Renesas specific) for communication between. Cortex-R / Cortex-A cores
- VIRTIO usage as a protocol between system partitions (not only VM-to-HV but other types of partitioning)
- Uses HW capability for the low-level mailbox / similar
- Subset of VIRTIO (can't assume access to whole memory as often done by VIRTIO to HV implementation)
- Can VIRTIO be transformed into a safety-optimized communication. E.g. some parts of memory only written by one party, read by the other. Also sealing needed (if it's a shared-memory buffer).
- Additional compute platform topics?
- Comparing hypervisors and simpler partitioning approaches (e.g. Jailhouse)
- Go through operating system kernel special needs for each popular OS choice.
- e.g. Is VIRTIO reasonably supported for RTOSes or other requirements?
- e.g. What is the impact of new RTOS initiatives, as well as migration of legacy code from dedicated hardware to a virtualized environment (because the hardware goes out of production or similar). Thread-X, AUTOSAR (OSEK), Zephyr, FreeRTOS, Arm MBed, (and no-RTOS bare-metal VMs).
Clock synchronization, real-time clock abstraction (probably a good topic for the AVPS)- Discussed today for the purpose of synchronized logs... but are not there more reasons? E.g. systems that can do load-balancing, redundancy (offloading, transferring tasks), don't they need a common time?
- Timer paravirtualization
- CPU scheduling reporting HV<->VM, e.g. kernels do not get accurate information about system load. Steal time reporting. The time while a VM was not scheduled, even though it should run (= Steal time).
- A spec from Arm ("Arm para-virtualized time" DEN0057A ) covers how to report steal time.
General topic: Needs for (easier, better) virtualization support in future SoCs.- Still examples of how IP-block diversity and limitations causes issues (32 bit device in an otherwise 64-bit architecture)
- Is virtualization truly a top priority for SoC vendors?
- Agreed definition of virtualization. Non-MMU systems seem to use the term even if the implementation is rather hardware separation.
...
- Real-timeish stuff
- What are the special considerations we need to work out to support real-time demands?
Impacts from safety certification, ASIL?- Look into Linaro presentation, Xen progress, etc. for some starting ideas. Also input from ELIZA project?
Proposals for leader/expert invitations
OPTEE maintainer Renesas. OPTEE related topics - Volodomyr Babchuk
...
Fulup checking with team who might be best suited to each topic.
(Monday 10 AM is not a good time slot)
Participants invitations and outreach
IPC topic
- Thomas, OpenSynergy, Peter (BMW), Kai,
- Francois-Frederic Ozog. Other Linaro representatives?
- Volodomyr (EPAM)
- AGL participants (Virtualization group? Instrument Cluster group?, etc.)
- GENIVI→COVESA mailing list outreach
- Stefano Stabellini (Xilinx)? (PST time zone, so 10 AM CET is not appropriate time)