Hello Stefan,
We are implementing hardware accelerated encryption for the CBE and have a question pertaining to this:
I wonder, is performance your primary motivation? If so, there might be other opportunities for optimization that are worth implementing first, before resorting to hardware acceleration. Should your primary motivation be the hiding of the keys from software, that's really cool!
How should the Cbe_crypto::Interface be implemented when the underlying hardware is asynchronous, e.g. driven by interrupts?
I think I understand the semantics of submit_encryption_request and encryption_request_complete but this mechanism doesn't seem to help with asynchronous completion. As far as I can tell, no signals are used with the Cbe_crypto::Interface
I cannot speak for the 'Cbe_crypto::Interface' specifically. But in general, a VFS plugin with outstanding requests is polled for the completion (request_complete) each time after I/O happened, i.e., after an I/O signal occurred.
You may take a look at how the implementation of the VFS terminal plugin responds to incoming data for reading ('_read_avail_handler') [1]. The 'read_avail_sigh' corresponds to your interrupt.
[2] https://github.com/genodelabs/genode/blob/master/repos/os/src/lib/vfs/termin...
To support batches of outstanding requests at the VFS (for hiding the latency of the crypto device), one may consider maintaining multiple file handles (at the client of the VFS plugin) where each file handle can have one request in flight. So the degree of parallelism can be tuned by the number of open file handles. Right now, I think that the CBE does not schedule more than one crypto request at a time though.
Cheers Norman