Carl: We have a root VM, it has access to all the memory and interrupts, it can delegate control, you can create new partitions and partition managers. Root VM has no special powers other than starting with all the resources. There is no API distinction between VMs, y you give them to other VMs if you wish
Carl EL2 looks like EL1 for better performance in IPC for example, use top address space for ALSR
Carl Those are the device trees by QEMU ? Alex they can be via grub, the standard way of doing it. Carl been thinking about different ways like the system device tree
Alex when you are talking secure VM - you are still traditional EL1/ EL2 and Linux VM is dropping its ability to access VM?
Carl: yes, not secure EL2 at all
Joakim Will trust zone be required ?
Carl could use OpenSSL and public keys and EL1
Joakim so you don't need this for development
Alex : the config is fundamental to virtio negotiation how will you address that?
Carl : the standard mmio is handled by hypervisor, it's the extensions that are problematic, virtio block does not cause an issue
Alex do you have examples, Srivatsa I did not find any with side effects
Carl : spec does not prohibit adding extensions with side effects
Alex have a backend virtio driver in the back end Kernal?
Srivatsa like a character interface, not with vhost user
Akashi-san do you have any table or chart that compare your HV with others?
Carl, we have internal docs, send us a mail and specify what you want to compare we can try to provide it
Joakim, what was the key missing feature from the existing HV such as Xen
Carl looked at HVs, the primary was having one for performance and power management scalability, the perf impact was too high, whilst keeping interrupt virtualization. We had to maintain android performance, to hit IoT automotive, mobile we need configurability.
Vincent ? the backend must use a custom interface, BE will have to be adjusted for your HV, we hope to have only one generic backend for all HV?
Srivista existing VMs have this issue, we will try to work with a common backend if it evolves. Perhaps using vhost user. We have not demonstrated a vhost user.
Alex, we now have 3 mechanisms
vhost user for KVM
char device for Gunyah
Do we abstract this out in a user space library used by the main virtio backend or abstract that to a standard kernel interface? This is worth discussing on the list.
@Alex Bennée forward notes on the system device tree to Carl
Carl pass along slides to attach to the meeting
Carl get back on which interfaces had side effects
@Alex Bennée start thread on the list about resolving the three mechanisms