Re: l4/sys/syscalls.h: No such file or directory
Hi,
On 09/15/2014 12:10 AM, Adam Lackorzynski wrote:
l4_fpage(i, L4_LOG2_PAGESIZE, L4_FPAGE_RWX),
A size needs to be specified for the fpage. And read-only will not be
enough, as for example, the stack needs to be written by the thread
functions.
Unfortunately, the issue is still the same.
I'm mapping everything from _stext L4_PAGEMASK to _end L4_PAGEMASK
after having mapped the pager to my new task, but each time one of my
created threads is still waiting for '1b'.
Besides, I'm getting a huge list of kernel warnings with the new
l4_fpage call that hasn't been there before. I've attached it to this mail.
So basically it's still the same code that I've sent you on September
5th, but in addition, there's the following loop beginning at line 57 in
lib/src/edft.c now:
extern char _stext[];
extern char _end[];
for (unsigned long i = ((unsigned long)_stext L4_PAGEMASK);
i ((unsigned long)_end L4_PAGEMASK);
i += L4_PAGESIZE)
{
l4_task_map(task_cap, L4RE_THIS_TASK_CAP,
l4_fpage(i, L4_LOG2_PAGESIZE, L4_FPAGE_RWX),
l4_map_control(i, 0, L4_MAP_ITEM_MAP));
}
Best regards,
Valentin
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 100a
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 100b
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1016
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1017
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1018
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1019
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101a
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101b
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101d
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101e
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101f
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1020
size: 0001 to [0xfcffae94/24]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 100a
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 100b
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1016
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1017
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1018
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1019
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101a
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101b
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101d
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101e
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101f
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1020
size: 0001 to [0xfcffae3c/27]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 100a
size: 0001 to [0xfcffade4/29]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 100b
size: 0001 to [0xfcffade4/29]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1016
size: 0001 to [0xfcffade4/29]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1017
size: 0001 to [0xfcffade4/29]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1018
size: 0001 to [0xfcffade4/29]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 1019
size: 0001 to [0xfcffade4/29]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101a
size: 0001 to [0xfcffade4/29]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101b
size: 0001 to [0xfcffade4/29]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101d
size: 0001 to [0xfcffade4/29]
KERNEL: Warning: nothing mapped: (Mem_space) from [0xfcffaeec/1a]: 101e
size:
Re: l4/sys/syscalls.h: No such file or directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Besides, I'm getting a huge list of kernel warnings with the new l4_fpage call that hasn't been there before. I've attached it to this mail. The kernel is complaining that you are trying to map memory from the sender that is not available in the sender's address space. As mapping basically means taking the sender's page table entries and putting them into the receiver's PT, the kernel does not know what to do. The trick here is that your pager needs to have the binary mapped into its own address space before handing it out. This can be achieved by accessing the binary's pages once during startup. (For convenience, see the l4_touch_ro() and l4_touch_rw() functions.) Bjoern -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQWkr0ACgkQP5ijxgQLUNmz1QCeIxkuSBgCvgDyndT497WYI1kO TgAAn24X79mdul5Q4wLoWM7g6oXpXVxv =LrVn -END PGP SIGNATURE- ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: Physical memory allocation to L4linux
Hey Adam, Thanks for the input. I will try changing one of the suggested functions. It would be great out of curiosity if you could elucidate why the following occurs. I see that there is a new iomem region being created and this happens only when I try to read from the mapped region - not until then. But none of this reaches the kernel or maybe I am not sure where to look.. In fact, I see that the init_mem file parses the kernel memory descriptors to find the regions. So under what circumstances does sigma0 go back to the kernel for mem/io? Thanks a lot! Ramya On 15 Sep 2014, at 00:38, Adam Lackorzynski a...@os.inf.tu-dresden.de wrote: On Fri Sep 12, 2014 at 16:34:17 +, Masti Ramya Jayaram wrote: I realized that the best place to modify sigma0's capabilities are when it is created. I see that this happens in kernel/fiasco/src/kern/kernel_thread-std.cpp in the init_workload() function. I do not exactly understand how sigma0 gathers all the capabilities - the code is a little hard to parse for me. Could someone explain this to me? Is there a way to pass only limited capabilities to sigma0 -aka, allow the default and then prune the resource tree? So, I've changed my mind, let's not modify the kernel but sigma0. This seems easier to me. As sigma0 is the root of memory this should not be a problem and can be argued. Sigma0 handles memory at first-come-first-serve approach and only gives it out once, so allocating it before servicing client requests should hide it from clients (see memmap.cc). However, there's also an unmap call which would need to be handled to not free it again. Another approach could be to exclude the memory region when initializing the internal data structures in init_mem.cc. Whatever works/fits better. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
Hi,
On Fri Sep 12, 2014 at 11:06:04 +, Stark, Josef wrote:
I've succeeded a bit since my original question, however it seems that I'm
stuck at the same or a related problem I mentioned there.
I have not found a solution so far.
I'll try to explain it as short as possible:
In my lua config file, I create an IPC gate, and then launch my manager and a
second ned instance, passing the IPC gate to both.
So now manager can send LUA commands through the IPC gate, which then ned
executes. This works so far.
But I also want newly (through manager and second ned) created tasks (or its
l4re thread) to be able to talk to manager.
For this, I created a second IPC gate in the config and also passed it to
manager and ned. Let's call it ipc_gate.
If, however, manager then issues e.g. the following LUA call (which creates
the new task and passes the IPC-gate capability),
the new task is still not able to communicate with manager.
hello = L4.default_loader:start( { caps = { ipc_gate = ipc_gate } },
rom/hello);
I guess it's because it's another layer and second ned doesn't know about
the IPC gate which is created
in the config file and thereby by first ned, even if I pass the capability to
him.
So, is there any way to enable IPC communication between manager and new
tasks created by the second ned?
If I understand correctly, I think you need to write
caps = { ipc_gate = L4.Env.ipc_gate }
L4.Env.ipc_gate is the cap given to the second ned by the first one, so
it's in its environment.
I tried to illustrate it by making a small diagram (it the font messes it up,
I've also attached a png image of it).
What I need is the ipc line between manager and hello to work.
Thanks, that helped!
Adam
--
Adam a...@os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/
___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: Physical memory allocation to L4linux
Hi, On Mon Sep 15, 2014 at 18:25:37 +, Masti Ramya Jayaram wrote: Thanks for the input. I will try changing one of the suggested functions. It would be great out of curiosity if you could elucidate why the following occurs. I see that there is a new iomem region being created and this happens only when I try to read from the mapped region - not until then. But none of this reaches the kernel or maybe I am not sure where to look.. Well, it should reach the kernel. For sigma0 mappings appear out of nothing (it's the root), so you should at least see it in the mapping loop in map_util.cpp's map() function (also see the comments on sigma0 there). In fact, I see that the init_mem file parses the kernel memory descriptors to find the regions. So under what circumstances does sigma0 go back to the kernel for mem/io? In this case there a fpage is created that is used in the reply to the client which will then create the mapping. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: l4/sys/syscalls.h: No such file or directory
On Mon Sep 15, 2014 at 15:50:07 +0200, Valentin Hauner wrote: On 09/15/2014 09:18 AM, Björn Döbel wrote: The trick here is that your pager needs to have the binary mapped into its own address space before handing it out. This can be achieved by accessing the binary's pages once during startup. (For convenience, see the l4_touch_ro() and l4_touch_rw() functions.) That worked, now the warnings do not appear any more. But it does not solve the real problem either. The code I've added: extern char _start[], _stext[], _sdata[], _end[]; // Adapted from examples/sys/start-with-exc/main.c l4_touch_ro(_start, _sdata - _start + 1); l4_touch_rw(_sdata, _end - _sdata); // Allocating stack and setting arguments to pass ... l4_touch_rw(thread_stack[count], sizeof(thread_stack[count])); l4_touch_ro(t-func, 1); // Mapping the pages with l4_task_map ... I've tried using _stext instead of _start, but still no success. A simple call of l4_touch_ro(_stext, _end - _stext) does not solve the issue either. I'm unsure what is the problem now. Doing the 4 l4_touch_* are the right thing to do. We should check whether there are more page faults happening. Enter jdb, then issue 'P*' (capital P) to enable page-fault logging, then 'g' for go. Let it run a second, then ESC again. Look at log with 'T' (capital T). Are there any entries? And generally, what are the threads doing? Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: Question about dec_lock_cnt method in Context class
Hi, On Tue Sep 09, 2014 at 17:18:16 -0400, Yuxin Ren wrote: There are three places where _running_under_lock is set to true; First one is just in the above loop. So this code will run only after it goes into the loop. This does not help explain why the code can go into the loop. The second is in Context::running_on_different_cpu() method in context.cpp file. if (EXPECT_FALSE(lock_cnt()) EXPECT_FALSE(!mp_cas(_running_under_lock, Mword(false), Mword(true return true; But this only happens when lock_cnt is non-zero. The third one is in Context::need_help method in context.cpp file. The method is called only when a thread tries to help the lock holder. I think this implies that the lock holder holds a lock and as a result, its lock_cnt is not 0. Just from those code, I think it is impossible for a thread that its _running_under_lock is true while its lock_cnt is 0. However now that the code is here, I want to know why the author add the extra check here? The author should have some reason to do so, right? Yes, probably. I can just give a fuzzy answer but the new release (due soon) will have a few changes in this area which are hopefully helping you too. Adam -- Adam a...@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/ ___ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Re: shared dataspace for l4re_kernel/ registering additional caps in ned
Hello Adam,
If I understand correctly, I think you need to write
caps = { ipc_gate = L4.Env.ipc_gate }
L4.Env.ipc_gate is the cap given to the second ned by the first one, so
it's in its environment.
thank you SO much, this works!
Josef
___
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
