lkl: add support for multiple system call threads

[ghost]

One of the current limitation of LKL is that all system calls are
serialized which limits the usability of LKL with threading applications.

As an example, lets take an application that waits for data on a
network socket using a blocking call to read() and occasionally
write()s data from another application thread. Once the read() syscall
has been issued, no write()s can be performed until the socket
receives some data and returns from the read().

This patch adds support for multiple system call threads so that the
application can issue multiple system calls. Note that only one system
call will be executed (i.e. LKL is still non SMP) at a time, but if
one system call blocks, another one can be executed.

In order to do so, the application must issue
lkl_create_syscall_thread from the context of a host thread. A new
kernel thread will be created and all subsequent system calls from the
host thread will be queued to the newly created kernel thread.

All the host threads that call lkl_create_syscall_thread must call
lkl_stop_syscall_thread and this must happen before lkl_halt is
called.

Signed-off-by: Octavian Purdila octavian.purdila@intel.com

[thehajime]

a couple of high-level comments.

1. i'm wondering if this is applicable with hijack library.
2. also wondering if this is applicable nt-host

[phhusson]

For the CI fail, I've noticed is that on 32bits architecture you must use lkl_sys_fcntl64, on 64bits you must use lkl_sys_fcntl.
Though I'm not sure what is the proper fix.

[ghost]

@phhusson correct, I am testing that right now :)

@thehajime I don't know if it is applicable to hijacking. Do you have any use-case in mind?

@thehajime yes, I will add nt support

[phhusson]

In posix-host.c, you'll have to rename gettid function, it conflicts when building on Android target

[pscollins]

This looks great!

---

Reviewed 9 of 9 files at r1.
Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

---

arch/lkl/kernel/syscalls.c, line 281 [r1] (raw file):
I think it's hard to keep straight the cases where we do/don't have the tls operations --- I think it might be easier if they got set at compile time, or we split the function in two depending on which case we're in.

---

arch/lkl/kernel/syscalls.c, line 294 [r1] (raw file):
Are we guaranteed to have this function? It looks like we might end up in the case where we don't have tls_* operations but syscall_thread_data_init fails, and we try to free it with a tls_free op that's NULL.

---

Comments from the review on Reviewable.io

[ghost]

Review status: 2 of 12 files reviewed at latest revision, 2 unresolved discussions.

---

arch/lkl/kernel/syscalls.c, line 281 [r1] (raw file):
I am not sure if splitting the functions is necessary, it looks reasonably simple to me.

---

arch/lkl/kernel/syscalls.c, line 294 [r1] (raw file):
Fixed.

---

Comments from the review on Reviewable.io

[pscollins]

Review status: 2 of 12 files reviewed at latest revision, 1 unresolved discussion.

---

arch/lkl/kernel/syscalls.c, line 281 [r1] (raw file):
All looks good to me, then.

---

Comments from the review on Reviewable.io

[pscollins]

Reviewed 3 of 10 files at r2, 7 of 7 files at r3.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

---

Comments from the review on Reviewable.io