Re: [PATCH v2 00/11] Drivers for gunyah hypervisor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux