Re: Noux application
Hello Joseph, On Tue, Oct 20, 2015 at 05:15:29PM +0200, Joseph Lee wrote: > Now i am trying implement the solution you have suggested me, but I have an > error. I place a file in a ram_fs file system and permit access to the file > system to a Noux process. I got the following log messages when I tried to > access the file from the Noux process. The name of the Noux process is > test. Appreciate if someone can help. > >no RM attachment (READ pf_addr=0 pf_ip=84ad from b2cfd156 test) >void Genode::Signal_transmitter::submit(unsigned int): failed - error 4 >static void Genode::Pager_object::_page_fault_handler(Genode::addr_t): > page fault, thread 'test', cpu 0, ip=84ad, fault >address=0x0 This means your test program is dereferencing a pointer to address 0, i.e., a NULL pointer. The message represent what you may know as "segmentation fault (SEGV)" from POSIX. So please check your program why the pointer you're dereferencing points to 0. Does the program work when compiled and executed on Linux? Regards -- Christian Helmuth Genode Labs http://www.genode-labs.com/ · http://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 -- ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Turmvilla scenario
Hello Vincent, On 20.10.2015 16:24, Vincent Digital wrote: > Are those quota overflow messages really a problem ? If you mean the "Quota exceeded" messages then it is normally no problem. Shortly afterwards of such a message you should see some "upgrading quota donation for ..." message. Mainly a server complains about insufficient memory resources to fulfil a request of a client. The client gets an appropriate exception and handles it by upgrading the memory resources of the session to this server and finally continues with the last operation. > [ESC: ScreenAttribs, 0]Assertion "block->tag == Block::Used" failed at > /home/vincent/genode-15.08/contrib/nova-61ea642d86312acd24698976f79d4530132c05a2/src/kernel/nova/src/buddy.cpp:143:void > Buddy::free(mword, Quota&) This is a bug which got fixed on Genode master already. Unfortunately - the Turmvilla scenario is not (yet) based on Genode master. (Issue 1672 on github). You may try to cherry-pick the corresponding commit and rebuild and replace the kernel on your branch. The bug triggered (until now) only on a 32bit Turmvilla setup. > NOVA Microhypervisor v7-a4a926a (x86_32): Oct 10 2015 18:00:57 [gcc 4.9.2] > > detected physical memory: 0x0001 - size: 0xfc00 > detected physical memory: 0x0002 - size: 0x3c00 You should build Turmvilla as 64bit. First you avoid the manual cherry-picking fixup. Secondly you would utilize all physical memory of your machine. On 32bit Genode/Nova all physical memory above 4G are not used. According to your memory map (the two "detected physical memory" messages above) you effectively don't use ~5GB RAM of your machine - which you definitely want to use ;-) Cheers, Alex. -- ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Noux application
Hi Christian, Thank you for your answers. You are right, you define my application scenario correctly. Now i am trying implement the solution you have suggested me, but I have an error. I place a file in a ram_fs file system and permit access to the file system to a Noux process. I got the following log messages when I tried to access the file from the Noux process. The name of the Noux process is test. Appreciate if someone can help. no RM attachment (READ pf_addr=0 pf_ip=84ad from b2cfd156 test) void Genode::Signal_transmitter::submit(unsigned int): failed - error 4 static void Genode::Pager_object::_page_fault_handler(Genode::addr_t): page fault, thread 'test', cpu 0, ip=84ad, fault address=0x0 Thanks, On Mon, Oct 19, 2015 at 11:34 AM, Christian Helmuth < christian.helm...@genode-labs.com> wrote: > Hello Joseph, > > On Sat, Oct 17, 2015 at 12:31:09PM +0200, Joseph Lee wrote: > > I am running a simple "tz_vmm" example in Genode on imx53 qsb. I have > Noux > > application which runs on top of Noux runtime inside the secure world. I > > wanted to access this Noux applications inside tz_vmm application, > calling > > a function of Noux application from tz_vmm code. But i have no idea how > to > > do that. Could anyone please give me some hint? > > What you're trying to achieve is to run two components (tz_vmm and a > Noux process) and trigger the execution of a function in the Noux > process by the tz_vmm component, right? I fear that my rephrasing does > not make anything more clear in your application scenario but I will > nevertheless try to propose a direction to follow. > > The Noux environment provides a POSIX runtime and POSIX (pthreads etc. > aside) is all about files when it comes to data exchange. So, you may > monitor a file (e.g., via select()) in the program. If you place the > file in a ram_fs and permit access to the file system to both, the > Noux process and tz_vmm, tz_vmm could trigger code execution in the > Noux process by writing into the file that is monitored. This scenario > should also work on any POSIX system where you may implement a > prototype. > > In case I got you wrong, please try to elaborate more on your goals or > give more details about your scenario. > > Regards > -- > Christian Helmuth > Genode Labs > > http://www.genode-labs.com/ · http://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 > > > -- > ___ > genode-main mailing list > genode-main@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/genode-main > -- ___ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Re: Turmvilla scenario
Hi, Alex, Okay, I tried to activate the Noux subsystem as advised by you after activiting the Linux subsystem. I encountered a total hang situation. In fact, anytime I activated the Noux subsystem, it always hanged. Nothing can move on the screen. As for the previous Linux subsystem which I thought was "hanged", actually after waiting for about 30 minutes, the Linux subsystem shows a "kernel panic". Any idea what I can do to troubleshoot further. I have attached the log after the Noux subsystem hang. Are those quota overflow messages really a problem ? NOVA Microhypervisor v7-a4a926a (x86_32): Oct 10 2015 18:00:57 [gcc 4.9.2] [ 0] CORE:0:0:0 6:25:5:4 [2] Intel(R) Core(TM) i5 CPU M 580 @ 2.67GHz [ 1] CORE:0:0:1 6:25:5:4 [2] Intel(R) Core(TM) i5 CPU M 580 @ 2.67GHz [ 3] CORE:0:2:1 6:25:5:4 [2] Intel(R) Core(TM) i5 CPU M 580 @ 2.67GHz [ 2] CORE:0:2:0 6:25:5:4 [2] Intel(R) Core(TM) i5 CPU M 580 @ 2.67GHz [ 0] DMAR:0xc23c5060 FRR:0 FR:0x5 BDF:0:2:0 FI:0x77fb7f000 Hypervisor features VMX Hypervisor reports 4x1 CPUs - boot CPU is 0 Hypervisor info page contains 99 memory descriptors: detected physical memory: 0x - size: 0x9e800 use physical memory: 0x - size: 0x9e000 detected physical memory: 0x0010 - size: 0xbb17c000 use physical memory: 0x0010 - size: 0xbb17c000 detected physical memory: 0xbb282000 - size: 0xdd000 use physical memory: 0xbb282000 - size: 0xdd000 detected physical memory: 0xbb40f000 - size: 0x6 use physical memory: 0xbb40f000 - size: 0x6 detected physical memory: 0xbb70f000 - size: 0x8000 use physical memory: 0xbb70f000 - size: 0x8000 detected physical memory: 0xbb71f000 - size: 0x4c000 use physical memory: 0xbb71f000 - size: 0x4c000 detected physical memory: 0xbb7ff000 - size: 0x1000 use physical memory: 0xbb7ff000 - size: 0x1000 detected physical memory: 0x0001 - size: 0xfc00 detected physical memory: 0x0002 - size: 0x3c00 map multi-boot module: physical 0x7bd3a000 -> [0x001d-0x002a02b0) - core map multi-boot module: physical 0x7be0b000 -> [0x2000-0x6031) - config map multi-boot module: physical 0x7be1 -> [0xa000-0x0006c2d8) - init map multi-boot module: physical 0x7be73000 -> [0x0007-0x000cec2c) - timer map multi-boot module: physical 0x7bed2000 -> [0xb000-0xb005f0f8) - part_blk map multi-boot module: physical 0x7bf32000 -> [0x002a4000-0x0031bd84) - ahci_drv map multi-boot module: physical 0x7bfaa000 -> [0xb0061000-0xb00f6000) - ld.lib.so map multi-boot module: physical 0x7c04 -> [0xb00f6000-0xb01f0950) - libc.lib.so map multi-boot module: physical 0x7c13b000 -> [0xb01f2000-0xb02188f4) - libm.lib.so map multi-boot module: physical 0x7c162000 -> [0x000dd000-0x000e53d0) - pthread.lib.so map multi-boot module: physical 0x7c16b000 -> [0x000e9000-0x000ed9d4) - libc_lock_pipe.lib.so map multi-boot module: physical 0x7c17 -> [0xb021a000-0xb022c9d0) - libc_terminal.lib.so map multi-boot module: physical 0x7c183000 -> [0xb022e000-0xb0312a70) - libiconv.lib.so map multi-boot module: physical 0x7c268000 -> [0xb0314000-0xb03e9e74) - stdcxx.lib.so map multi-boot module: physical 0x7c33e000 -> [0xb03eb000-0xb0520a9c) - rump.lib.so map multi-boot module: physical 0x7c474000 -> [0xb0522000-0xb0673c24) - rump_fs.lib.so map multi-boot module: physical 0x7c5c6000 -> [0xb0675000-0xb069b234) - rump_fs map multi-boot module: physical 0x7c5ed000 -> [0xb069d000-0xb0f8b1bc) - virtualbox map multi-boot module: physical 0x7cedc000 -> [0xb0f8d000-0xb0fee5d4) - ps2_drv map multi-boot module: physical 0x7cf3e000 -> [0xb0ff1000-0xb1116c74) - usb_drv map multi-boot module: physical 0x7d064000 -> [0xb111a000-0xb116ae30) - acpi_drv map multi-boot module: physical 0x7d0b5000 -> [0xb116e000-0xb11dfe24) - platform_drv map multi-boot module: physical 0x7d127000 -> [0xb11e3000-0xb1271c84) - fb_drv map multi-boot module: physical 0x7d1b6000 -> [0xb1275000-0xb12c8fdc) - device_pd map multi-boot module: physical 0x7d20a000 -> [0xb12cc000-0xb132ce98) - rtc_drv map multi-boot module: physical 0x7d26b000 -> [0xb133-0xb138fbb0) - input_merger map multi-boot module: physical 0x7d2cb000 -> [0xb1393000-0xb141470c) - nic_drv map multi-boot module: physical 0x7d34d000 -> [0xb1418000-0xb14983e4) - nitpicker map multi-boot module: physical 0x7d3ce000 -> [0xb149c000-0xb14f5a74) - vbox_pointer map multi-boot module: physical 0x7d428000 -> [0xb14f9000-0xb155ed40) - nit_fb map multi-boot module: physical 0x7d48e000 -> [0xb1562000-0xb15c61ac) - report_rom map multi-boot module: physical 0x7d4f3000 -> [0xb15cb000-0xb1634aa4) - wm map multi-boot module: physical 0x7d55d000 -> [0xb1638000-0xb1698ca8) - decorator map multi-boot module: physical 0x7d5be000 -> [0xb169c000-0xb16f2504) - floating_window_layouter map multi-boot module: physical 0x7d615000 -> [0xb16f6000-0xb1757f7c
