users

users@lists.genode.org

1 participants
2310 discussions

Checkpointing dataspaces in core
by Denis Huber 03 Aug '16

03 Aug '16

Dear Genode community, I want to implement a new service (class Cr_session) residing in core which provides an Rpc method to checkpoint the state of a specific component (given its label string). I am using Genode 16.05 and the foc kernel (pbxa9 build). The first step is to store the content of the address space of the compoent. My approach is the following: 1) First a test component is created which shall be checkpointed. The component counts an integer every second. In base/src/test/cr_service/counter/main.cc (newly created file): !void Component::construct(Genode::Env &env) !{ ! unsigned int n = 0; ! Timer::Connection timer(env); ! ! while(1) ! { ! Genode::log(n); ! n++; ! timer.msleep(1000); ! } !} 2) To realize the CR service in core, I want to find the specific PD session of the test component. Therefore a separate Sliced_heap exclusively for Pd_session_component objects is created in core's main function. In base/src/core/main.cc: !static Sliced_heap pd_sliced_heap(env()->ram_session(), env()->rm_session()); ![...] !static Pd_root pd_root(e, e, pager_ep, &pd_sliced_heap); 2) The CR service is registered and the special Sliced_heap is passed to the Root_component<Cr_session_component> object. In base/src/core/main.cc: !static Cr_root cr_root(e, &sliced_heap, &pd_sliced_heap); ![...] !static Local_service ls[] = { ! Local_service(Cr_session::service_name(), &cr_root), ![...] !} 3) In the implementation of the checkpoint method the Sliced_heap (stored in _alloced_pds) is searched for a Pd_session_component with a specific label string. The class implementing the Cr service (Genode::Cr_session_component : Rpc_object<Cr_session>) is a friend class in Sliced_heap and is allowed to access the _blocks member variable containing the Pd_session_component objects. In base/src/core/include/cr_session_component.h (newly created file): !bool checkpoint(String<64> label) !{ ! Pd_session_component *pd = nullptr; ! bool found = false; ! Sliced_heap::Block *b = _alloced_pds->_blocks.first(); ! for(; (b != 0) && !found; b = b->next()) ! { ! pd = reinterpret_cast<Pd_session_component*>(b + 1); ! if(label == pd->_label.string) found = true; ! } 4) The Pd_session_component object is known and now it shall be used to access the test component's address space content. To retrieve the content I want to attach the Dataspace of the component's Region_map to core's Region_map. In base/src/core/include/cr_session_component.h (newly created file): ! Capability<Region_map> rm_cap = pd->address_space(); ! Region_map_client rm_client(rm_cap); ! void* addr = core_env()->rm_session()->attach(rm_client.dataspace()); ! return true; !} 5) After invoking rm_client.dataspace() the Rpc method never returns and the test scenario times out. What am I doing wrong? I compared the source code of other core services with the CR service and found no usage of classes derived from Rpc_client belonging to other core services. Is it not possible to use Rpc methods in core? I tested another solution where I only use Rpc_objects directly. I used pd_session_component::address_space_region_map() to access the address_space directly, where I think to find the memory content of the test component (Please correct me, if I am wrong). The following listing replaces the listing in step 4. In base/src/core/include/cr_session_component.h (newly created file): ! Dataspace_capability ds_cap = pd->address_space_region_map().dataspace(); ! char* addr = core_env()->rm_session()->attach(ds_cap); ! log("Attaching dataspace: Returned pointer: ", addr); ! ! Dataspace_component *ds_comp = pd->address_space_region_map().dataspace_component(); ! log("Reading dataspace component"); ! log("phys_addr = ", ds_comp->phys_addr(), " size = ", ds_comp->size(), " writable = ", ds_comp->writable() ? "true" : "false"); The output of the log function was the following: Attaching dataspace: Returned pointer: 0x00000000 Reading dataspace component phys_addr = 0 size = 3221221376 writable = false Now I got a null pointer and cannot read the content of the Region_map of the test component. Can someone help me to answer the following questions: * Can I use Capability invokation in core, where the Rpc_object belongs to another core service? If yes, how? Perhaps, my problem is the correct retrieval of the Pd_session_component, thus I can invalid Capabilities. * Why do I get an invalid pointer from the attach method of core's Region_map? Is it not allowed to attach dataspaces in core? Are they already attached in core, and I only need the pointer to the memory? Is the Dataspace_capability invalid? Kind regards Denis

2 4

Genode Scheduling TrustZone Demo
by Stefan Brenner 01 Aug '16

01 Aug '16

Hi, we are using inject_irq() from Martin Stein to inject interrupts into the normal world VM running Linux. When measuring the time between issuing inject_irq() and actually arriving at the ISR in normal world (using CPU performance counters in CPU cycles granularity) we can see that this always requires at least 10 million cycles, which is 10ms at 1Ghz and exactly what is defined as cpu_fill_ms in base-hw/src/core/include/kernel/configuration.h. If we set cpu_fill_ms to 1, we can measure that it only requires 1 million cycles. Apparently it is not possible to set values below 1 (some assertion fails on compile). Is there another option, probably a more elegant one, that allows the acceleration of interrupt injection? Best, Stefan. -- M.Sc. Stefan Brenner Institute of Operating Systems and Computer Networks Distributed Systems Group TU Braunschweig www: https://www.ibr.cs.tu-bs.de/users/brenner mail: brenner@...290... xmpp: brenner@...369...

3 2

Re: Sending data to offline system doesn't work reliably
by Johanna Steer 29 Jul '16

29 Jul '16

Hi Sebastian, i am using QEMU. Regards, Johanna >Hi Johanna, > >On 07/26/2016 10:58 AM, Johanna Steer wrote: >> Hi, >> >> i am working on a toolchain monitoring the schedluing behavior of the >> fiasco.oc kernel. The data is monitored through the trace service (quota >> for trace is 2M). >> It is then sent to an offline system through an active TCP/IP connection >> and written into a database. VDE is used for that and i am working on >> Ubuntu 14.04. >> My problem is that the data isn't sent reliably. I am executing a >> periodic task that returns zero and exits. The only thing that varies is >> the period. After 20 seconds the tasks stop, the monitored data is >> gathered and then sent to the offline system. >> The kernel says that it is sending the data, but the system freezes at >> times and the data simply doesn't arrive. >> The system reacts quite randomly: Sometimes it sends the files, >> sometimes it doesn't. Sometimes i get an error (shown below). It seems >> easier to send small data sizes (around 200KB), above 700KB hardly >> anything works. In between, it might work or not. As far as i have >> experienced there is no pattern behind it. >> >> I tried the tests before with only 1M quota for trace and the >> reliability improved with 2M quota. However, with 4M it gets worse again >> and the error occures more often. >> >> >> Here ist the error: >> >> [init -> nic_drv] tx fifo overrun, ignore packet > >This error comes from the lan9118 NIC driver. It is a network card >driver we use for the PBXA9 ARM platform in Qemu only. We have never >used it on real hardware, and therefore, it might not work correctly >there. What SoC are you using or do you use Qemu? > >Regards, > >Sebastian > >> : spawn id exp6 not open >> while executing >> "expect { >> -i $running_spawn_id $platform_msg { puts stderr "Error: >> platform rebooted unexpectedly"; exit -4 } >> -i $running_spawn_id -re $wait_for_re..." >> (procedure "wait_for_output" line 22) >> invoked from within >> "wait_for_output $wait_for_re $timeout_value $qemu_spawn_id" >> (procedure "run_log" line 28) >> invoked from within >> "run_log $wait_for_re $timeout_value" >> (procedure "run_genode_until" line 28) >> invoked from within >> "run_genode_until forever" >> (file "/home/johanna/Bachelorarbeit/genode/repos/dom0/run/dom0.run" >> line 132) >> invoked from within >> "source $include_name" >> ("foreach" body line 6) >> invoked from within >> "foreach include_name [get_cmd_arg --include ""] { >> # first check if the include name is absolute >> if {[string first "/" $include_name] == 0} { >> puts ..." >> (file "/home/johanna/Bachelorarbeit/genode/tool/run/run" line 642) >> >> ------------------------------------------------------------------------------ >> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic >> patterns at an interface-level. Reveals which users, apps, and protocols are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity planning >> reports.http://sdm.link/zohodev2dev >> _______________________________________________ >> genode-main mailing list >> genode-main@...52... >>https://lists.sourcef <https://lists.sourceforge.net/lists/listinfo/genode-main>

2 1

Running Heeselicht scenario on qemu
by Parfait Tokponnon 28 Jul '16

28 Jul '16

Hello everybody; I has been fed up with restarting my computer after every compilation so, I have decided to try running the Heeselicht scenarion on qemu (not very wise but just to speed the development process). But I got some errors concerning acpi table parsing, resulting in the intel framebuffer not well detected. So because I am very poor in qemu mastering, may someone tell me whether it would take a lot of work to port the heeselicht scenario on qemu? Or join me on doing this? Any help is welcome (Here is the log file for those who are interested) -- Parfait T.

2 2

Sending data to offline system doesn't work reliably
by Johanna Steer 27 Jul '16

27 Jul '16

Hi, i am working on a toolchain monitoring the schedluing behavior of the fiasco.oc kernel. The data is monitored through the trace service (quota for trace is 2M). It is then sent to an offline system through an active TCP/IP connection and written into a database. VDE is used for that and i am working on Ubuntu 14.04. My problem is that the data isn't sent reliably. I am executing a periodic task that returns zero and exits. The only thing that varies is the period. After 20 seconds the tasks stop, the monitored data is gathered and then sent to the offline system. The kernel says that it is sending the data, but the system freezes at times and the data simply doesn't arrive. The system reacts quite randomly: Sometimes it sends the files, sometimes it doesn't. Sometimes i get an error (shown below). It seems easier to send small data sizes (around 200KB), above 700KB hardly anything works. In between, it might work or not. As far as i have experienced there is no pattern behind it. I tried the tests before with only 1M quota for trace and the reliability improved with 2M quota. However, with 4M it gets worse again and the error occures more often. Here ist the error: [init -> nic_drv] tx fifo overrun, ignore packet : spawn id exp6 not open while executing "expect { -i $running_spawn_id $platform_msg { puts stderr "Error: platform rebooted unexpectedly"; exit -4 } -i $running_spawn_id -re $wait_for_re..." (procedure "wait_for_output" line 22) invoked from within "wait_for_output $wait_for_re $timeout_value $qemu_spawn_id" (procedure "run_log" line 28) invoked from within "run_log $wait_for_re $timeout_value" (procedure "run_genode_until" line 28) invoked from within "run_genode_until forever" (file "/home/johanna/Bachelorarbeit/genode/repos/dom0/run/dom0.run" line 132) invoked from within "source $include_name" ("foreach" body line 6) invoked from within "foreach include_name [get_cmd_arg --include ""] { # first check if the include name is absolute if {[string first "/" $include_name] == 0} { puts ..." (file "/home/johanna/Bachelorarbeit/genode/tool/run/run" line 642)

2 1

CPU execution time
by Johanna Steer 26 Jul '16

26 Jul '16

Hi, i am monitoring the cpu execution time on the fiasco.oc kernel. The time is given in a unit at least 100 times smaller than milliseconds, but i can't find the exact size anywhere. My laptop has the i7-4500U Processor with 1.8 GHz if that helps. Regards, Johanna

2 1

Using interrupts to control scheduling decisions in base-hw
by Adrian Hengelhaupt 26 Jul '16

26 Jul '16

Hello, My task is to implement a preemptive scheduler for a zynq-board. Therefore I've tried to figure out how the cpu_scheduler program in repos/baseh-hw/run/cpu_scheduler.run works and whether it can be used as a foundation for my task. So, my question is: How can I utilize interrupts in order to make subsequent scheduling decisions? Thanks in advance! Greetings Adrian

2 1

Exceptions in RPC Functions
by Nobody III 25 Jul '16

25 Jul '16

RPC functions often throw exceptions. What exactly happens when these exceptions are thrown? Most importantly, what happens on the server side? Does the RPC call just end as soon as the error is thrown, allowing the server and the session to continue normally?

2 1

i.mx53 NIC driver
by Jinhong Kim 25 Jul '16

25 Jul '16

Hi, Genode experts Currently I'm working with the TrustZone VMM example from Genode based on Genode 16.05 on i.MX53 QSB. And I want to move NIC device driver from normal world to secure world. To achieve this, 1. Change FEC setting of <CSU.h> to SECURE. (original configuration of FEC is UNSECURE.) However, data abort is occured during boot on imx53 qsb. Is there any hints or suggestion to solve this problem? Thank you for your attention. Regards Jinhon Kim

2 1

TRACE confusion
by Johannes Schlatow 21 Jul '16

21 Jul '16

Hi everyone, I'm a bit confused by the trace_session and its implementation: The documentation suggests that the trace buffer is assigned to a thread. On the other hand, the trace subject is associated with a session label. What I conclude from this is that a thread be identified by multiple trace subjects but can only be assigned a single trace policy and trace buffer, which makes the interface quite confusing. I also had a glance at the implementation and noticed that the Trace::Subject has its own buffer, which is forwarded to the Trace::Source. If I understand this correctly, the Trace::Source is coupled to a thread. I therefore assume that I can only trace one trace subject (associated with the same thread) at a time. Is this correct? Cheers Johannes

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users