...
Minute takers according to this page
February 19th, 2019
Participants:
- Bernhard Rill
- Gunnar Andersson
- Dimitri Morozov
- Vasco Fachin
- Kai Lampka
- Sang-Bum Suh
- Artem Mygaiev
Apologies:
- Philippe Robin
Review plan for next meetings
Gunnar: Table has updated status. Let's review...
Crypto -
Input from Sang-Bum?
S-B: Should be included in VIRTIO. There is one chapter...
Artem: Let me share what I know:
That component would be utilized by the guest operating system. The cryptography accelerator components.
...When we are thinking about TPM chips. Those are is single-threaded machines.
...so that's why VIRTIO proposed virtual TPM.
...We haven't seen in the past that this...
...Security cannot be provided for threaded programming support. Virtual crypto, should be discussed.
Artem: For ARM it works like this.
...The execution level of security is higher than the hypervisor. If there is a task running in EL3 it will always have higher priority than hypervisor.
...Therefore, Hypervisor cannot influence what's happening on the secure world.
...Note of course SEL2 implementations coming in next ARM architecture which we talked about efore.
...To implement virtualization support, we have upstreams VM IDs to OPTEE. This is already included. R-Car is supported.
...For the guest on ARM, if OPTEE is used (or any other TEE supporting virt) they will be transparent operationally hardware sharing inside trustzone has to be implemented, again out of control for HV.
...Architecturally I can only explain how that work on current ARM architecture, not Intel.
V8.4 There is the alpha draft of the specification available.
Bernhard: Yes, the one we discussed before. NDA only -- you need to send me an email to request. (ongoing)
Artem: Thus on ARM even with current implementation, HV is out of picture.
...You need to support it in TEE software. You also need to implement sharing on the secure device drivers level.
...The guest will be able to access it directly without virtualization supprot
... HV needs to pass ??? VMID
.. with security policies you may allow or disallow security, trapping some syscalls.
... Intel is probably different
Sang-Bum: It might be true, if sec controlled by ARM SoC hardware
...Running trust zone area. HV only running at normal.
...Before HV applied to ARM, operating system utilize ARM hardwarae, should be embedded within that operating system.
...Applying HV at normal domain, the operating system manage the ARM hardware, also should be run on hardware in some cases.
...HV only has control over ARM hardware, If the other guest operating system
Gunnar: Sang-bum can you put some of these thoughts into writing. (I cannot take notes fast enough)
Sang-Bum: Yes.
Artem: for Embedded, there is a standard called Global Platform. Many trusted execution environments make use of this.
Sang-bum: This is covering trusted execution environments. We can us global platform APIs.
AI(Artem): Provide references go global platform
Planning SBSA timing
12 March: CET 11-12 is OK?
Sang-Bum: Yes, 7PM for me, it is OK
Artem: I might be travelling on 12th... I will know in a few days.
Gunnar: I think this time was generally OK with Anup. I will check.
Sang-Bum: I'm not available next week tuesday, but 5th March is OK.
AI: Where is Global Platform defined?
AI: Gunnar - confirm 11.00 for 12 March
USB Virtualiztion
Gunnar: Let's go through the proposal I wrote based on previous discussions
Artem: Actually I have found more info. Some solutions for virtualized USB exist. I don't yet know if they make sense and are useful or not.
Gunnar: Please provide links.
Artem: I will check (until next week) what is possible with respect to USB virtualization.s
Gunnar: I then ask if the *configuration* of the pass-through can be standardized
Artem: Well at least on Xen it is all defined using device-tree (according to Linux kernel standard).
... Some patches for partial device tree. In other words, HV gets a big one, and splits the pass-through according to some, configuration and injects the results into the guest DTs.
Gunnar: So that is Linux (guest) specific? Just let me ask, for example, Xen runs Windows - how would that work?
Artem: Windows - done with ACPI on Intel at least... I have not looked because I work on ARM and Windows on ARM is...well has a difficult history.
Gunnar: OK, sure, but let's say FreeRTOS...
Artem: Everything has to be statically configured. We do the configuration at compile-time in that case (compiling the RTOS hardware part)
...Configuration can be passed to other domains
...In smaller RTOS they don't always support injecting a hardware description like device tree so we need to recompile.
Gunnar: Other vendors? Are there different ways to configure this in every hypervisor?
Sang-bum: I think it's vendor specific. It's hard to follow for example device-tree without licensing concerns (if your software is not GPL licensed)
Gunnar: I think I understand... it might be difficult to reuse major things link device-tree without also reusing the implementation of it.
... but you could write your own specification and implement it?
Sang-bum: I don't think we need to discuss a standard specification for how hardware is integrated. It is a kind of implementation detail.
Gunnar: How is it done in OpenSynergy, if you want to share that detail...
Dmitry: I think some XML based configuration files. And special compiler to capture this input. I agree this is implementation specific
Gunnar: OK, statement about this being proprietary is basically correct. I might stillrewrite it a bit based on this input.
Kai: I have sent a proposal for talk at AMM. Idea: VIRTIO might be used to get operating system interaction also when running on bare hardware.
(What follows is a discussion (on overtime) between Artem and Kai about this idea. We expect more interesting discussion on this.)
Kai: consider different operating systems running on different (dedicated) cores. E.g. RTOS on a small core.
Artem: With this idea, sharing hardware between real-time and non-real time domain worries me.
Kai: I meant this, you can use VIRTIO protocol to exchange between domains.
Artem: OK, but you don't need the whole VIRTIO then. There are often hardware mailboxes for example, as alternative (to virtqueues)
Kai: Think about for example VIRTIO NET.
February 12th, 2019
Participants:
- Bernhard Rill (taking minutes)
- Philippe Robin
- Gunnar Andersson
- Dimitri Morozov
- Vasco Fachin
- Kai Lampka
- Erik Jaegervall
...
- Date for the SBSA presentation is 05th of March. Charles Garcia from Arm is going to execute this presentation. Exact timeslot will be defined based on the doodle from Gunnar (note below)
- API standardization:
- Dmitry mentioned that OpenSynergy is working on an Audio implementation (they evaluate if they can transfer Audio frames via VirtIO)
- It might be that OASIS is working in this area. It might be good that OpenSynergy gets in contact with them.
- EPAM Artem has summarized the sensors section. Feedback from the team is needed
- USB: Vasco mentioned that a full virtualization of an USB is very hard; it might be desirable to setup a pass-through device
- What are the use-cases which would lead towards a need to fully virtualize an USB? TBD
- Limiting factors for a full virtualized USB are
- complexity of the USB (DMA support)
- Security
- Action item Vasco is going to summarize his view on USB in the summary table
- Bluetooth virtualization is most likely not needed
- Memory ballooning is as well out of scope
- Gunnar has updated the chapters network, cryptography and text console. Feedack is welcome!
- Dmitry mentioned that OpenSynergy is working on an Audio implementation (they evaluate if they can transfer Audio frames via VirtIO)
- Different timeslot for a call that Anup can join for the watchdog discussion.
- Action item Gunnar will send a Doodle link
- Access to ArmV8.4 Trustzone API specification (Secure Partition Interface specification)
- let Bernhard know if you would like have access to this specification (under NDA)
- Events:
- Embedded world
- GENIVI AMM Munich
February 5, 2019
Participants:
...