virtio-device in µC of a SoC

["Gittinger Joerg (XC-ECO/ESH2)" <Joerg.Gittinger@de.bosch.com>]

Hi,

I have a concrete request for a use-case to support by virtio, but am not sure where and how to discuss it. So please let me know if this mailing list is not the proper place. In detail I would like to get answers to:
1) Is this the proper mailing list/place to discuss?
2) Is the use case worth to discuss or is it out of the scope of virtio?
3) How should it be discussed: with individual design proposals/code/patches or with sort of a concise design document?

The roughly outlined use case we are interested in is this: 
On many embedded System-on-Chips (SoCs) nowadays microcontrollers for real-time OS (RTOS) and micro processors for Rich OS like Linux share access to a common region in RAM. The idea is that if the RTOS on the µC would implement virtio-device(s) using MMIO transport as a shared memory in RAM, virtio-drivers implemented in Linux could directly communicate with the device in the RTOS on the µC (yes, given the precondition that all queues + buffers are in common RAM and if cross-processor IRQs exist). There would be no hypervisor, the MMIO transport resides in a RAM area. Virtio devices like crypto, socket, entropy, net,... could be implemented on the RTOS and used by a rich OS like Linux out-of-the-box on such SoCs.

Unfortunately this is currently not supported with virtio MMIO transport, because for instance the feature and queue negotiation sequences at device initialization phase implicitly require synchronous actions by the device on single MMIO-write operations performed by the driver which cannot be accomplished with pure memory accesses. For instance the sequence:

driver -> device: write IDX to register DeviceFeaturesSel
driver <- device: read register DeviceFeatures (<-- value dependent on IDX)

will not succeed because the driver running on a different processor would have to wait until the device had recognized IDX and had written the correct feature bits word to the DeviceFeatures register in the common MMIO RAM. Supporting this use case with virtio with the existing MMIO transport would require extending MMIO with additional synchronization options between such write and read operations. Or a completely new synchronous MMIO transport would be required.

Best regards + appreciating your comments
Joerg