Hi Stefan,
(secure world=Genode, normal world=Linux)
- normal world allocates a buffer in normal world memory
- normal world issues an SMC and transmits the buffer's address to
secure world where addresses are translated 3) secure world stores the address 4a) normal world writes something to the shared buffer and modifies some meta data structures. Basically, it writes to the metadata "Hey, secure world, there is something for you". 4b) secure world busy-waits (ugly) until it reads something new from the normal world, and starts processing it.
are you using the tz_vmm example at _os/src/server/tz_vmm/_ as blue print?
The points 1 to 4a are consistent with my suggestion. But instead of letting the tz_vmm poll for new information (4b), I propose to let the normal world issue an SMC call each time it has written something meaningful to the buffer. So the tz_vmm could simply block for SMC calls (wait_for_signal) and each time a signal comes in, it would process a new request. Not before finishing the work, it would pass control back to the normal world (by issuing _vm->run()). With "finishing the work" I mean that the tz_vmm applies changes to its internal state. It should not wait for a blocking operation between the reception of a signal and calling '_vm->run()' because this would stall the normal world.
Essentially, tz_vmm should be understood as a state machine. State changes are triggered by signals and applied in the '_handle_vm' function. An SMC request is such a signal.
Basically, we implemented the buffer as a message queue abstraction, so it will offer read() and write() messages, and it allows to send messages of (almost) unlimited size via the queue.
That sounds fine.
Cheers Norman