On 09/08/2022 02:38, Elliot Berman wrote:
On 8/2/2022 2:24 AM, Dmitry Baryshkov wrote:
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. >
The mailbox framework can only fit with message queues and not doorbells
or vCPUs. The mailbox framework also relies on the mailbox being defined
in the devicetree. RM is an exceptional case in that it is described in
the devicetree. Message queues for other VMs would be dynamically
created at runtime as/when that VM is created. Thus, the client of the
message queue would need to "own" both the controller and client ends of
the mailbox.
I'd still suggest using the mailbox API for the doorbells. You do not
have to implement the txdone, if I'm not mistaken.
RM is not loaded or managed by Linux, so I don't think remoteproc
framework provides us any code re-use except for the subdevices code.
Remoteproc is much larger framework than just the subdevices code, so I
don't think it fits well overall.
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.
We don't want to limit VM configuration to the devicetree as this limits
the number and kinds of VMs that can be launched to build time. I'm not
sure if you might have seen an early presentation of Gunyah at Linaro?
In the early days of Gunyah, we had static configuration of VMs and many
properties of the VMs were described in the devicetree. We are moving
away from static configuration of VMs as much as possible.
ack, this is correct.
[1]: https://chromium.googlesource.com/chromiumos/platform/crosvm
--
With best wishes
Dmitry
