On Sat Apr 23, 2022 at 00:40:05 +0200, Paul Boddie wrote:
> On Friday, 22 April 2022 01:16:44 CEST Paul Boddie wrote:
> >
> > On Thursday, 21 April 2022 22:57:40 CEST Adam Lackorzynski wrote:
> > >
> > > Maybe it helps to share some code here?
> >
> > I suppose it might be best to condense this into an example that uses the
> > basic L4Re APIs instead of my own libraries (that wrap those APIs), so as
> > not to confuse things. I'll try and put that together tomorrow.
>
> So, I finally got to looking at this and making it self-contained, with an
> archive of the code available here:
>
> https://www.boddie.org.uk/downloads/tests_l4re.tar.bz2
>
> This is a package that should work within the L4Re build system containing
> two
> source files: a trivial program (exec_payload_l4re.c) and a loader program
> that attempts to create a new task to load and start the trivial program
> (exec_l4re.cc). Both programs are statically linked.
>
> Note that the loader program does not do all the work to start the program,
> focusing only on being able to resolve the initial page fault. So, although
> it
> attempts to set up various capabilities and other resources, it doesn't even
> initialise the stack or map in other regions that would be needed to actually
> run the program.
>
> The log when running the loader program using the supplied configuration will
> report page faults occurring as follows:
>
> exec_l4r| page_fault(0x1000ae4, 0x1000ae3) -> 0x1000ae0 (0x4)...
> exec_l4r| -> l4_fpage(0x40000, 18, 0x5) @ 1000000
> exec_l4r| page_fault(0x1000ae5, 0x1000ae3) -> 0x1000ae0 (0x5)...
> exec_l4r| -> l4_fpage(0x40000, 18, 0x5) @ 1000000
>
> Here, the received fault is decoded and the flexpage for returning is
> described. When I switch on page fault and IPC logging (P*, I*, IR+) in jdb,
> I
> get entries like this:
>
> 0047 answ [00000040] L=0 err=0 (OK) (1000038,40495)
>
> pf: 0043 pfa=0000000001000ae3 ip=0000000001000ae3 (rp) spc=0xffffffff13dc5cb8
> err=15
> ipc: 0047 send rcap->[C:INV] DID=43 L=0 [0000000000000040]
> (0000000001000038,0000000000040495) TO=INF
>
> Here, thread 0047 belongs to the loader program, and 0043 belongs to the
> trivial payload program.
>
> It is entirely possible that I am not sufficiently initialising the created
> task, but it surprises me that the page fault does not get resolved, and I
> did
> some old-fashioned debugging with Fiasco to establish that the mapping does
> occur. One difference between the above and my previous report is that the
> mapped region is now significantly smaller, since I am now using a binary
> file
> installed in the "rom" as a module, not the initially generated ELF binary.
>
> When looking for other code that might be doing this kind of thing, I
> remembered L4Linux which seems to use the C APIs. Much of what it is doing is
> similar to what I have been trying, although it seems to use the "alien"
> thread mechanism at various points, which I don't fully understand.
>
> Anyway, I hope that I am making some obvious mistake that just hasn't been
> obvious to me. Although there were examples in the package that was available
> via Subversion (and maybe still is available via Git), they covered alien
> threads and the vCPU support, but I couldn't find anything related to task
> creation in its own right. Interestingly, I did find this:
>
> https://github.com/phipse/L4RTEMS/blob/master/l4/pkg/RTEMS_wrapper/server/src/
> wrapper_1.cc
>
> But it is also using the vCPU feature. However, it does seem to attempt ELF
> header decoding and related activities, so it might still prove to be a
> useful
> reference.
>
> Thanks once again for listening!
Thanks for the example.
I believe I see the issue but first I immediately change to buf_log2size
to 12 for the reason of less suprise, and did not change further on the
sizes. Then I noticed your way of handling the UTCB involved allocating
memory. That's not needed. With the fpage you specify the window of the
UTCB memory in the other task, so no need to allocation memory in the
launcher task, if it is for reserving the virtual memory.
Then, the issue is that posix_memalign allocates memory which does not
have the x-bit set, i.e., is memory that is not executable.
Change it to
buf = (char *)mmap(NULL, region_size, PROT_EXEC | PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANON, -1, 0);
if (buf == MAP_FAILED)
{
printf("Could not reserve memory.\n");
return 1;
}
and it should work (it did for me).
Adam
_______________________________________________
l4-hackers mailing list
l4-hackers@os.inf.tu-dresden.de
https://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
