On Thu, Sep 23, 2021 at 3:00 AM users-request@lists.genode.org wrote:
[CAUTION: Non-UBC Email]
Send users mailing list submissions to users@lists.genode.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.genode.org/listinfo/users or, via email, send a message with subject or body 'help' to users-request@lists.genode.org
You can reach the person managing the list at users-owner@lists.genode.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of users digest..."
Today's Topics:
- Re: Getting Started with Genode (Christian Helmuth)
- Re: CBE crypt interface (Norman Feske)
- Re: CBE crypt interface (Stefan Thöni)
Message: 1 Date: Thu, 23 Sep 2021 10:02:00 +0200 From: Christian Helmuth christian.helmuth@genode-labs.com To: users@lists.genode.org Subject: Re: Getting Started with Genode Message-ID: 20210923080200.GB2343@genode-labs.com Content-Type: text/plain; charset=utf-8
Hello Sid, welcome to the list!
On Thu, Sep 23, 2021 at 01:04:28 CEST, Sid Agrawal wrote:
- *Running the hello_tutorial*: the hello_tutorial job on qemu does
not
finish to completing and times out. Below are my steps on ubuntu
20.04.1. I
am using the Genode development container https://genodians.org/skalk/2020-09-29-docker-devel, so the tools should not an issue. I also tried it outside the container.
git clone git://github.com/genodelabs/genode.git cd genode tool/ports/prepare_port sel4 tool/ports/prepare_port grub2 tool/create_builddir x86_64
cd x86_64/build/ # Change build/x86_64/etc/build.conf. # Change kernel to sel4 and add hello_tutorial diff etc/build.conf.old etc/build.conf
20c20
< #KERNEL ?= nova
KERNEL ?= sel4
85a86
REPOSITORIES += $(GENODE_DIR)/repos/hello_tutorial
make make hello make run/hello # This times out as shown below.
[init -> hello_server] creating root component [0m [0m [init -> hello_client] upgrading quota donation for PD session (0 bytes, 4 caps) [0m [0m [init] child "hello_server" requests resources: cap_quota=3 [0m [0m [init] child "hello_client" requests resources: ram_quota=0, cap_quota=4 [0m [0m Error: Test execution timed out
Any comments on what I am doing wrong would be very helpful. Secondly,
what
would be the best way to go about debugging an issue like this.
I suppose you succeded in running the scenario on Linux and NOVA like follows.
make run/hello KERNEL=linux BOARD=linux make run/hello KERNEL=nova
For seL4 I can reproduce what you pasted above, so the issue is related to the used platform. As the log output states "hello_server" is requesting more resources and requires cap_quota (capability quota) increased during an operation that requires 3 caps. A look into the init configuration (see hello.run) reveals the following.
<!-- all components get 50 capabilities per default -->
<default caps="50"/>
Now you may grant the component some more caps to make it run successully by changing
<start name="hello_server" caps="54">
to the hello_server start node and running
make run/hello KERNEL=sel4
This results in additional resource requests
[init] child "hello_server" requests resources: ram_quota=0, cap_quota=4
The reason is that the seL4 platforms works quite different from NOVA and expectedly Linux, which results in a higher capability consumption of the used software stack.
The following start nodes render the scenario working again.
<start name="hello_server" caps="58"> ... <start name="hello_client" caps="51">
Thank you, Christian, for the resolution as well as the explanation.
Please see Chapters "Resource trading" [1] and "Resource assignment" [2] in the Genode Foundations book for a thorough explanation.
[1] https://genode.org/documentation/genode-foundations/21.05/architecture/Resou... [2] https://genode.org/documentation/genode-foundations/21.05/system_configurati...
Regards
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · https://www.genodians.org/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Message: 2 Date: Thu, 23 Sep 2021 10:19:03 +0200 From: Norman Feske norman.feske@genode-labs.com To: users@lists.genode.org Subject: Re: CBE crypt interface Message-ID: 7c847df2-79db-2075-9a77-8bf0cd94fde8@genode-labs.com Content-Type: text/plain; charset="utf-8"
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
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth