On 02/08/2022 00:12, Elliot Berman wrote:
Gunyah is a Type-1 hypervisor independent of any
high-level OS kernel, and runs in a higher CPU privilege level. It does
not depend on any lower-privileged OS kernel/code for its core
functionality. This increases its security and can support a much smaller
trusted computing base than a Type-2 hypervisor.
Gunyah is an open source hypervisor. The source repo is available at
https://github.com/quic/gunyah-hypervisor.
The diagram below shows the architecture.
::
Primary VM Secondary VMs
Is there any significant difference between Primary VM and other VMs?
+-----+ +-----+ | +-----+ +-----+ +-----+
| | | | | | | | | | |
EL0 | APP | | APP | | | APP | | APP | | APP |
| | | | | | | | | | |
+-----+ +-----+ | +-----+ +-----+ +-----+
---------------------|-------------------------
+--------------+ | +----------------------+
| | | | |
EL1 | Linux Kernel | | |Linux kernel/Other OS | ...
| | | | |
+--------------+ | +----------------------+
--------hvc/smc------|------hvc/smc------------
+----------------------------------------+
| |
EL2 | Gunyah Hypervisor |
| |
+----------------------------------------+
Gunyah provides these following features.
- Threads and Scheduling: The scheduler schedules virtual CPUs (VCPUs) on
physical CPUs and enables time-sharing of the CPUs.
Is the scheduling provided behind the back of the OS or does it require
cooperation?
- Memory Management: Gunyah tracks memory ownership and use of all memory
under its control. Memory partitioning between VMs is a fundamental
security feature.
- Interrupt Virtualization: All interrupts are handled in the hypervisor
and routed to the assigned VM.
- Inter-VM Communication: There are several different mechanisms provided
for communicating between VMs.
- Device Virtualization: Para-virtualization of devices is supported using
inter-VM communication. Low level system features and devices such as
interrupt controllers are supported with emulation where required.
After reviewing some of the patches from the series, I'd like to
understand, what does it provide (and can be provided) to the VMs.
I'd like to understand it first, before going deep into the API issues.
1) The hypervisor provides message queues, doorbells and vCPUs
Each of resources has it's own capability ID.
Why is it called capability? Is it just a misname for the resource ID,
or has it any other meaning behind? If it is a capability, who is
capable of what?
At this moment you create allocate two message queues with fixed IDs for
communication with resource manager. Then you use these message queues
to organize a console and a pack of tty devices.
What other kinds of services does RM provide to the guest OS?
Do you expect any other drivers to be calling into the RM?
What is the usecase for the doorbells? Who provides doorbells?
You mentioned that the RM generates DT overlays. What kind of
information goes to the overlay?
My current impression of this series is that you have misused the
concept of devices. Rather than exporting MSGQs and BELLs as
gunyah_devices and then using them from other drivers, I'd suggest
turning them into resources provided by the gunyah driver core. I
mentioned using the mailbox API for this. Another subsystem that might
ring the bell for you is the remoteproc, especially the rproc_subdev.
I might be completely wrong about this, but if my in-mind picture of
Gunyah is correct, I'd have implemented the gunyah core subsytem as
mailbox provider, RM as a separate platform driver consuming these
mailboxes and in turn being a remoteproc driver, and consoles as
remoteproc subdevices.
I can assume that at some point you would like to use Gunyah to boot
secondary VMs from the primary VM by calling into RM, etc.
Most probably at this moment a VM would be allocated other bells,
message queues, etc. If this assumption is correct, them the VM can
become a separate device (remoteproc?) in the Linux device tree.
I might be wrong in any of the assumptions above. Please feel free to
correct me. We can then think about a better API for your usecase.
--
With best wishes
Dmitry
