users May 2020

users@lists.genode.org

9 participants
9 discussions

Announcement: Genode OS Framework version 20.05 released
by Christian Helmuth 28 May '20

28 May '20

The principal topic of Genode 20.05 is "consolidation", which is a polite synonym for hard work hidden from the user and developer under the hood of our widely stabilized API. The strong motivation for this work stems from the confrontation of our software with increasingly complex real world workloads. Along these lines we generalized of our central component for managing platform I/O resources with a from-the-scratch platform driver for ARM as the first step. Also, we unified the virtualization support for ARMv7/ARMv8 and added support for Qemu virt ARM platforms for 32 and 64 bit. A functional highlight marks the feature completeness of our block-encryption component CBE implemented in ADA/SPARK clearing the way to integrate this feature into Sculpt soon. Also in a joint effort with the community, we improved Genode on Linux from a sheer development tool to a product-ready platform with effective sandboxing of components based on seccomp and object capabilities. So, adopters can employ Genode/Linux and start right away with the application development on the target platform, and at any time migrate transparently to a microkernel. Last but not least, don't miss the annual update of the Genode Foundations book. More highlights of the current release are - Capability-based security via seccomp on Linux - Feature-completeness of our consistent block encrypter - Consolidation of the framework API and feature set - New revision of the Genode Foundations book - Ability to host board support outside the Genode source tree - Platform-driver architecture for the ARM universe - Unified virtual-machine monitor for ARMv7 and ARMv8 - Qemu-virt platform support - MSI-X support on x86 - Improved CPU affinity management on the NOVA hypervisor The complete release documentation for the version 20.05 is available at https://genode.org/documentation/release-notes/20.05 Have fun -- Christian Helmuth Genode Labs https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/ Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

1 0

Deadlock in combination with pthread, lwip and grpc
by Sid Hussmann 22 May '20

22 May '20

Dear Genodians, during stress testing a gRPC server with parallel connections I witness a race condition where the gRPC server component becomes unresponsive, while being able to respond to Genode heartbeats. Examining the different threads using GDB after the deadlock occurs, I notice one thread waiting at `spinlock_lock` after `Lwip::File_system::write()` threw an `Insufficient_buffer` exception: ```gdb (gdb) t 13 [Switching to thread 13 (LWP 520409)] #0 spinlock_lock (lock_variable=lock_variable@entry=0x501cad40 <Linker::mutex()::_mutex>) at /home/user/genode/repos/base/include/spec/x86/cpu/atomic.h:51 51 return tmp == cmp_val; (gdb) bt #0 spinlock_lock (lock_variable=lock_variable@entry=0x501cad40 <Linker::mutex()::_mutex>) at /home/user/genode/repos/base/include/spec/x86/cpu/atomic.h:51 #1 Genode::Cancelable_lock::lock (this=this@entry=0x501cad40 <Linker::mutex()::_mutex>, myself=...) at /home/user/genode/repos/base/src/lib/base/lock.cc:71 #2 0x000000005004fa02 in Genode::Mutex::acquire (this=this@entry=0x501cad40 <Linker::mutex()::_mutex>) at /home/user/genode/repos/base/src/lib/base/mutex.cc:27 #3 0x00000000500bb050 in Genode::Mutex::Guard::Guard (mutex=..., this=<synthetic pointer>) at /home/user/genode/repos/base/include/base/mutex.h:40 #4 dl_iterate_phdr (callback=callback@entry=0x500a3a40 <_Unwind_IteratePhdrCallback>, data=data@entry=0x41ffa1b0) at /home/user/genode/repos/base/src/lib/ldso/exception.cc:41 #5 0x00000000500a4caf in _Unwind_Find_FDE (pc= 0xaf828f2 <Libc::Vfs_plugin::write(Libc::File_descriptor*, void const*, unsigned long)+722>, bases=bases@entry=0x41ffa418) at /data/genode/contrib/gcc-893d85767720fc2b3c695c56d737d2307b1f2229/src/noux-pkg/gcc/libgcc/unwind-dw2-fde-dip.c:469 #6 0x00000000500a12a3 in uw_frame_state_for (context=context@entry=0x41ffa370, fs=fs@entry=0x41ffa460) at /data/genode/contrib/gcc-893d85767720fc2b3c695c56d737d2307b1f2229/src/noux-pkg/gcc/libgcc/unwind-dw2.c:1257 #7 0x00000000500a2bdb in _Unwind_RaiseException (exc=0x501be8e8 <Genode::init_cxx_heap(Genode::Env&)::initial_block+7528>) at /data/genode/contrib/gcc-893d85767720fc2b3c695c56d737d2307b1f2229/src/noux-pkg/gcc/libgcc/unwind.inc:104 #8 0x00000000500a98c5 in __cxa_throw () at /data/genode/contrib/gcc-893d85767720fc2b3c695c56d737d2307b1f2229/src/noux-pkg/gcc/libgcc/unwind-dw2-fde.h:157 #9 0x000000000ad17404 in non-virtual thunk to Lwip::File_system::write(Vfs::Vfs_handle*, char const*, unsigned long long, unsigned long long&) () from vfs_lwip.lib.so #10 0x000000000af828f3 in Libc::Vfs_plugin::write ( this=0xaff6dc0 <unmanaged_singleton<Libc::Kernel, 8, Genode::Env&, Genode::Allocator&>(Genode::Env&, Genode::Allocator&)::object_space+9272>, fd=0x7ffff7c586b0, buf=0x7ffff7abfd6e, count=3419) at /home/user/genode/repos/libports/src/lib/libc/vfs_plugin.cc:806 #11 0x000000000af711e7 in do_sendto (fd=<optimized out>, buf=0x7ffff7abfd6e, len=3419, dest_addr=<optimized out>, dest_addrlen=<optimized out>, flags=<optimized out>) at /home/user/genode/repos/libports/src/lib/libc/socket_fs_plugin.cc:176 #12 0x000000000af72a28 in Libc::Socket_fs::Plugin::write (this=<optimized out>, fd=<optimized out>, buf=<optimized out>, count=<optimized out>) at /home/user/genode/repos/libports/src/lib/libc/socket_fs_plugin.cc:1099 #13 0x00000000011c9f60 in tcp_send (fd=84, msg=msg@entry=0x41ffb2f0, additional_flags=additional_flags@entry=0) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/lib/iomgr/tcp_posix.cc:958 #14 0x00000000011ca18a in tcp_flush (tcp=tcp@entry=0x7ffff7d7da80, error=error@entry=0x41fff238) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/lib/iomgr/tcp_posix.cc:1499 #15 0x00000000011ca56b in tcp_write (ep=0x7ffff7d7da80, buf=<optimized out>, cb=<optimized out>, arg=<optimized out>) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/lib/iomgr/tcp_posix.cc:1636 #16 0x000000000116c6d0 in write_action (gt=0x7ffff7e90e20) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/lib/iomgr/closure.h:110 #17 write_action_begin_locked (gt=0x7ffff7e90e20) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/ext/transport/chttp2/transport/chttp2_transport.cc:956 #18 0x00000000011b25c1 in grpc_combiner_continue_exec_ctx () at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/lib/iomgr/combiner.cc:252 #19 0x00000000011b9818 in grpc_core::ExecCtx::Flush (this=this@entry=0x41fff3b0) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/lib/iomgr/exec_ctx.cc:156 #20 0x0000000001217b64 in grpc_core::ExecCtx::~ExecCtx (this=0x41fff3b0, __in_chrg=<optimized out>) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/lib/iomgr/exec_ctx.h:124 #21 grpc_call_start_batch (call=<optimized out>, ops=0x41fff470, nops=3, tag=0x41fff8b0, reserved=<optimized out>) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/lib/surface/call.cc:1973 #22 0x0000000001006eaa in grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal::CallOpSendMessage, grpc::internal::CallOpServerSendStatus, grpc::internal::CallNoOp<4>, grpc::internal::CallNoOp<5>, grpc::internal::CallNoOp<6> >::ContinueFillOpsAfterInterception (this=0x41fff8b0) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/include/grpcpp/impl/codegen/call.h:72 #23 0x00000000010067ec in grpc::internal::CallOpSet<grpc::internal::CallOpSendInitialMetadata, grpc::internal::CallOpSendMessage, grpc::internal::CallOpServerSendStatus, grpc::internal::CallNoOp<4>, grpc::internal::CallNoOp<5>, grpc::internal::CallNoOp<6> >::FillOps (this=0x41fff8b0, call=<optimized out>) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/include/grpcpp/impl/codegen/interceptor_common.h:235 #24 0x0000000001008aa4 in grpc::internal::Call::PerformOps (ops=0x41fff8b0, this=<optimized out>) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/include/grpcpp/impl/codegen/call.h:69 #25 grpc_impl::internal::RpcMethodHandler<helloworld::Greeter::Service, helloworld::HelloRequest, helloworld::HelloReply>::RunHandler (this=this@entry=0x7ffff7f55300, param=...) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/include/grpcpp/impl/codegen/method_handler_impl.h:90 #26 0x000000000126891a in grpc_impl::Server::SyncRequest::CallData::ContinueRunAfterInterception (this=this@entry=0x7ffff7cdb650) at /home/user/genode/contrib/stdcxx-79ad8821269a443aab21bfc1d0e9b8913332b6d1/include/stdcxx/bits/move.h:182 #27 0x000000000126916c in grpc_impl::Server::SyncRequest::CallData::Run (resources=true, global_callbacks=..., this=0x7ffff7cdb650) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/cpp/server/server_cc.cc:489 #28 grpc_impl::Server::SyncRequestThreadManager::DoWork (this=<optimized out>, tag=<optimized out>, ok=<optimized out>, resources=<optimized out>) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/cpp/server/server_cc.cc:900 #29 0x00000000012afa66 in grpc::ThreadManager::MainWorkLoop (this=0x7ffff7f4f460) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/cpp/thread_manager/thread_manager.cc:211 #30 0x00000000012afcb0 in grpc::ThreadManager::WorkerThread::Run (this=0x7ffff7eae6e0) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/cpp/thread_manager/thread_manager.cc:43 #31 0x00000000011ae0ac in grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::operator() (__closure=0x0, v=<optimized out>) at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/lib/gprpp/thd_posix.cc:140 #32 grpc_core::(anonymous namespace)::ThreadInternalsPosix::<lambda(void*)>::_FUN(void *) () at /home/user/genode/contrib/protobuf_grpc-3414c16ccc9b43fa990653590ac986adf8780fce/src/lib/grpc/src/core/lib/gprpp/thd_posix.cc:145 #33 0x000000000af66391 in Libc::Pthread::Thread_object::entry (this=0x7ffff7d374f8) at /home/user/genode/repos/libports/src/lib/libc/pthread.cc:71 #34 0x0000000050096295 in Genode::Thread::_thread_start () at /home/user/genode/repos/base/include/base/output.h:54 #35 0x00000000500abab2 in thread_start () at /home/user/genode/repos/base-linux/src/lib/syscall/spec/x86_64/lx_clone.S:62 (gdb) ``` At this point, I also notice many threads being stuck after a `pthread_exit` call: ```gdb (gdb) t 10 [Switching to thread 10 (LWP 520056)] #0 pseudo_end () at /home/user/genode/repos/base-linux/src/lib/syscall/spec/x86_64/lx_syscall.S:29 29 ret /* Return to caller. */ (gdb) bt #0 pseudo_end () at /home/user/genode/repos/base-linux/src/lib/syscall/spec/x86_64/lx_syscall.S:29 #1 0x000000005004f3fd in lx_futex (val=0, op=0, uaddr=<optimized out>) at /home/user/genode/repos/base-linux/src/lib/syscall/linux_syscalls.h:436 #2 thread_stop_myself (myself=<optimized out>) at /home/user/genode/repos/base-linux/src/include/base/internal/lock_helper.h:62 #3 Genode::Cancelable_lock::lock (this=this@entry=0x426ffd60, myself=...) at /home/user/genode/repos/base/src/lib/base/lock.cc:128 #4 0x000000005004f5a3 in Genode::Cancelable_lock::lock (this=this@entry=0x426ffd60) at /home/user/genode/repos/base/src/lib/base/lock.cc:66 #5 0x0000000050075990 in Genode::Lock::lock (this=<optimized out>) at /home/user/genode/repos/base/include/base/lock.h:33 #6 Genode::Blockade::block (this=<optimized out>) at /home/user/genode/repos/base/include/base/blockade.h:31 #7 Genode::sleep_forever () at /home/user/genode/repos/base/src/lib/base/sleep.cc:21 #8 0x000000000af66332 in pthread_exit (value_ptr=0x0) at /home/user/genode/repos/libports/src/lib/libc/pthread.cc:558 #9 0x000000000af663a3 in Libc::Pthread::Thread_object::entry (this=0x7ffff7d7a078) at /home/user/genode/repos/libports/src/lib/libc/pthread.cc:71 #10 0x0000000050096295 in Genode::Thread::_thread_start () at /home/user/genode/repos/base/include/base/output.h:54 #11 0x00000000500abab2 in thread_start () at /home/user/genode/repos/base-linux/src/lib/syscall/spec/x86_64/lx_clone.S:62 (gdb) ``` Despite our best efforts we have failed to pinpoint the problem so far. A few questions: 1. Is the spinlock really a problem here? 2. I was able to reproduce this problem using the newest version of gRPC [1] and the current `genodelabs/staging` branch. Reading [0] makes me wonder if the problem can be seen as "yet another instance where the VFS synchronization has bitten us". 3. Unlike `lwip`, `lxip` seems to give up after just one or two connections with this warning: `_wait_and_dispatch_one_io_signal called from non-entrypoint thread "pthread.5"`. May this issue be related or should we just focus on `lwip`? 4. In the GDB backtrace e.g. of `thread 13` at `#5` I notice a path to `libgcc` that does not belong to my machine. Is this neglegtable or does it mess with my GDB output? We just updated the `grpc` and `protobuf` libraries [1], which we will publish shortly. The problem however persists with both versions. To reproduce this issue, please checkout branch [2] and run `grpc-server-lwip` under Linux. Starting multiple client connections in parallel can be done by running `./stress_parallel_execute.sh 10.0.2.55:8899` using [3]. Note that the problem sometimes takes a few thousand of parallel connections to reproduce. [0] https://github.com/genodelabs/genode/issues/3738#issuecomment-620496337 [1] https://github.com/trimpim/genode-world/tree/xxxx-update_protobuf_grpc_port [2] https://github.com/sidhussmann/genode-world/tree/grpc-server-race-condition [3] https://github.com/sidhussmann/grpc-connection-stress Cheers, Sid -- Sid Hussmann CTO & Founder gapfruit AG Baarerstrasse 135 6300 Zug - Switzerland sid.hussmann(a)gapfruit.com

2 11

Fifo<>::Element is missing a virtual destructor
by Stefan Thöni 22 May '20

22 May '20

Hi Genodians I would like to create a hierarchy of classes on top of Fifo<>::Element so these object can be stored in fifos: class A : public Fifo<A>::Element { virtual method() = 0; }; class B : public A { method() override { ... } }; This won't compile because Fifo<>::Element is missing a virtual destructor. Is there any reason for this? What do you think about adding the virtual destructor to Fifo<>::Element? Kind regards Stefan -- Freundliche Grüsse Stefan Thöni Chairman of the Board Senior Security Architect +41 79 610 64 95 gapfruit AG Baarerstrasse 135 6300 Zug https://gapfruit.com

2 1

Resource trading between client and server
by Roman Iten 14 May '20

14 May '20

Dear Genodians, Imagine a certain server component. The memory usage of server depends on the number of clients and their behavior. Therefore, in order to create a session to server, a client component has to pay for the server-side allocations. So far so easy. Now imagine that server is a child of server_init and client is a child of client_init. Both init's are siblings. I would expect that still client - and only client - has to pay for the server-side allocations. But the session creation fails when client_init and/or server_init assigned all of it's resources to it's children (RAM/CAP quota saturation). I'm able to circumvent the session creation issue (reliably) by configuring (both) init's with resource preservation that take the server-side allocations into account. From my understanding this implies that actually the parent components have to pay at least temporary during session creation. Is my interpretation correct? Cheers, Roman

2 1

A simple window manager
by Paul Dufresne 13 May '20

13 May '20

I was thinking about an old idea, for a very simple screen manager... and it is becoming even a bit more complete. So I would like to share it with you... because I think it would be a nice fit for Genode. So at first I was thinking a very simple model... -Almost all the screen for one application -a bar at the bottom with: -- one left button at the left -- one right button at the right -- a title in the middle (of the application) Left, and right would navigate through the open applications Then the idea that screens are large enough for two windows wide came to my mind. Second model (at first): -Almost all the screen for one application -a bar at the bottom with: -- one left button at the left -- one right button at the right -- a title in the middle -- a 1 button -- a 2 button -- a pin button So like before, but the 1 button is activated at the beginning. If you click the 2 button, the screen divide in 2 windows So now you got: -left button in bottom left -right button in bottom right -the left window for application 1 -- bottom-right title info for application 1 -- bottom-left1 the 1 2 buttons (2 is activated) -- bottom-left2 the pin button -the right window for application 2 -- bottom-left title info for application 2 -- bottom-right1 the 1 and 2 buttons (2 is activated) -- bottom-right2 the pin button So the idea, is that under each application you got: -the pin button, that when activated, the application don't change when doing right and left button So if one of the side is pinned, right and left buttons affect only the other side. If none is pinned, pressing left (right goes to left, and right is filled with next open application). If none is pinned, pressing right (left goes to right, and left is filled with previous open application). (my guess is that if the right and the left applications are pinned, the left and right buttons are deactivated) - the 1 button, that return to the single application screen, with the current application And then, I realized we need the some more info... So I would add a upper-bar with: -a menu button for the applications to launch -clock -Quit button -mixer button -network button - etc. Does it seems a good idea?

3 2

compiling problem on run/demo
by Paul Dufresne 11 May '20

11 May '20

Hi! I am coming back to Genode after a few year of absence. I am on Fedora 32, x64 architecture. So I installed: genode-toolchain-19.05-x86_64.tar.xz , downloaded genode-20.02 (tought I first it was the toolchain...). Then began to read: https://genode.org/documentation/genode-foundations/19.05/getting_started/U… and now when I do: [paul@localhost x86_64]$ make run/demo KERNEL=linux BOARD=linux including /home/paul/genode-20.02/tool/run/power_on/linux including /home/paul/genode-20.02/tool/run/log/linux including /home/paul/genode-20.02/tool/run/boot_dir/linux including /home/paul/genode-20.02/repos/os/run/demo.run building targets: app/status_bar test/nitpicker spawn make app/status_bar test/nitpicker make[1] : on entre dans le répertoire « /home/paul/genode-20.02/build/x86_64 » checking library dependencies... Library ldso-startup Library ld Library base Program test/nitpicker/testnit Program app/status_bar/status_bar make[1] : on quitte le répertoire « /home/paul/genode-20.02/build/x86_64 » genode build completed Error: missing depot archives: genodelabs/bin/x86_64/base-linux/2020-02-27 genodelabs/bin/x86_64/demo/2020-02-27 genodelabs/bin/x86_64/fb_sdl/2020-02-27 genodelabs/bin/x86_64/global_keys_handler/2020-02-27 genodelabs/bin/x86_64/init/2020-02-27 genodelabs/bin/x86_64/input_filter/2020-02-27 genodelabs/bin/x86_64/nit_focus/2020-02-27 genodelabs/bin/x86_64/nitpicker/2020-02-27 genodelabs/bin/x86_64/report_rom/2020-02-27 genodelabs/bin/x86_64/rom_filter/2020-02-27 You may create the following archives locally: /home/paul/genode-20.02/tool/depot/create genodelabs/bin/x86_64/base-linux genodelabs/bin/x86_64/demo genodelabs/bin/x86_64/fb_sdl genodelabs/bin/x86_64/global_keys_handler genodelabs/bin/x86_64/init genodelabs/bin/x86_64/input_filter genodelabs/bin/x86_64/nit_focus genodelabs/bin/x86_64/nitpicker genodelabs/bin/x86_64/report_rom genodelabs/bin/x86_64/rom_filter CROSS_DEV_PREFIX=/usr/local/genode/tool/19.05/bin/genode-x86- make: *** [Makefile:324: run/demo] Error 1 But when I do the given I command I get: Program lib/initramfs/lx_init BUILD initramfs /usr/bin/ld: cannot find -lc collect2: error: ld returned 1 exit status make[6]: *** [/home/paul/genode-20.02/depot/genodelabs/src/base-linux/2020-02-27/src/lib/initramfs/target.mk:12: initramfs] Error 1 make[5]: *** [var/libdeps:109: lx_init.prg] Error 2 make[4]: *** [Makefile:287: gen_deps_and_build_targets] Error 2 make[3]: *** [/home/paul/genode-20.02/tool/depot/mk/build_bin_archive:200: /home/paul/genode-20.02/depot/genodelabs/bin/x86_64/base-linux/2020-02-27.build/bin] Error 1 make[2]: *** [/home/paul/genode-20.02/depot/var/build.mk:48: genodelabs/bin/x86_64/base-linux/2020-02-27] Error 2 make[1]: *** [/home/paul/genode-20.02/tool/depot/build:134: execute_generated_build_mk_file] Error 2 make: *** [/home/paul/genode-20.02/tool/depot/create:59: build] Error 2 [paul@localhost x86_64]$ make run/demo KERNEL=linux BOARD=linux including /home/paul/genode-20.02/tool/run/power_on/linux including /home/paul/genode-20.02/tool/run/log/linux including /home/paul/genode-20.02/tool/run/boot_dir/linux including /home/paul/genode-20.02/repos/os/run/demo.run building targets: app/status_bar test/nitpicker spawn make app/status_bar test/nitpicker make[1] : on entre dans le répertoire « /home/paul/genode-20.02/build/x86_64 » checking library dependencies... Library ldso-startup Library ld Library base Program test/nitpicker/testnit Program app/status_bar/status_bar make[1] : on quitte le répertoire « /home/paul/genode-20.02/build/x86_64 » genode build completed So, rather than just give up, I am writing this message.

2 3

Clipboard size
by Colin Parker 08 May '20

08 May '20

Hello, I am having a lot of fun with Sculpt, but I do wonder something about copy/paste. Whenever I copy a large portion of text, a subsequent paste only gives the first part. This is most noticeable within a VM, but I wonder, since the VM can move the clipboard to/from Sculpt, if a Sculpt clipboard size limit is coming into play? If so, can the clipboard be made bigger? Failing that, can I disable clipboard integration with the VM? Apologies if this was settled a long time ago. Regards, Colin

2 3

Re: Re: Benchmark Armv8 VMM (Stefan Kalkowski)
by Chris Hofer 07 May '20

07 May '20

Hi Stefan, Hi Chris, On Wed, May 06, 2020 at 01:23:59PM +0200, Chris Hofer wrote: > Hi, > > to measure the performance overhead of the Armv8 Genode VMM, I ran some > benchmarks (cyclictest and lmbench). I compared it against a native Linux > installation on the Imx8-evk board (same kernel version). For some > measurements (for example fork + executing /bin/sh from lmbench), I observe > counter-intuitive results in the sense that the virtualized version runs > *faster* than the native one (Vm 1,1ms vs. native 2,5ms). > > My understanding is, that the virtual timer offset (cntvoff_el2) is not used > and thus, the guest sees wall clock time. I would expect that the > virtualization incurs an overhead and this overhead manifests itself in > longer (wall clock) time measurements. > >> Correct, but you assume that native Linux and virtualized version run >> with the same frequencies (cpu + timer) - don't you? >> >> Actually, I think the timer frequency should be constant in both >> scenarios, whereby at least the cpu will be controlled dynamically in >> the native Linux case. >> >> When comparing such complex scenarios to avoid mistakes I would >> strongly encourage you to not measure time on-target. It often leads >> to wrong assumptions. It is better to measure long-term scenarios from >> another host. If you need to measure micro-benchmarks, you might loop >> the operation quite often and measure the whole time-span outside, and >> divide the result. >> >> Alternatively, if you insist to measure on-target, you can instrument >> Linux to use a constant CPU frequency (google for "linux cpu >> governor"). Moreover, you might check whether the timer frequency is >> the same in both settings (CNTFRQ_EL0) - well it should be. Thank you for this advice; it makes perfect sense to capture the time off-target. I finally found a big mistake in my setup to measure the duration of forking a process and calling /bin/sh. The native installation uses a dynamically linked shell and the guest has a statically linked binary. After using statically linked binaries on both systems I get reasonable results. Nevertheless, I will take advice and verify the measurements off-target. Best, Chris

1 0

Benchmark Armv8 VMM
by Chris Hofer 07 May '20

07 May '20

Hi, to measure the performance overhead of the Armv8 Genode VMM, I ran some benchmarks (cyclictest and lmbench). I compared it against a native Linux installation on the Imx8-evk board (same kernel version). For some measurements (for example fork + executing /bin/sh from lmbench), I observe counter-intuitive results in the sense that the virtualized version runs *faster* than the native one (Vm 1,1ms vs. native 2,5ms). My understanding is, that the virtual timer offset (cntvoff_el2) is not used and thus, the guest sees wall clock time. I would expect that the virtualization incurs an overhead and this overhead manifests itself in longer (wall clock) time measurements. Do you have any explanation for this or give me a hint on how to confirm correctness of measurements? Best, Chris

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users May 2020