## Pending problems

#### on a write, ARM reports a read pagefault first if no mapping was present (u)

> I fear, we have to do this evil code analysis thing on a translation abort to figure out whether it was a read or a write access.
> Write accesses on read-only mapped pages are fine - these cause a permission abort.

#### L4/Linux enter_kdebugs "non linux task" (u)

> The linux kernel received an IPC with no error code, but the sender's thread_id was not valid.
> Non-solution: Some exits in sys_ipc returning an error code didn't keep the dest_id as specified.

> Note: Not seen anymore since 2000-04-10.

##

2000-01-18

#### IPC via sysenter/sysexit works (u)

> We use a modified version of Jochen's proposal for the int 0x30 replacement
> The kernel esp is restored from the tss.esp0 location directly after entering the kernel. This saves the expensive (serializing) wrmsr to update the MSR_0x175.

##

2000-01-17

#### First steps towards the sysenter/sysexit IPC mechanism

> sysenter: MSR_0x174 -> cs; MSR_0x174 + 8 -> ss; MSR_0x175 -> esp; MSR_0x176 -> eip
> The esp register is overwritten on sysenter, no return information is saved implicitly.
> sysexit: MSR_0x174 + 16 -> cs; MSR_0x174 + 16 + 8 -> ss; ecx -> esp; edx -> eip
> The registers ecx and edx must contain esp and eip and thus are not free for use.

> The kernel esp (MSR_0x175) must be updated on every thread switch.
> Jochen proposes to store the return address on the user's stack and to keep the user's esp in ecx.

##

2000-01-16

#### An IPC with timeout NEVER returns with error code 0x20 (timeout) (u)

> Problem: This happened due to not dequeueing threads from the wakeup queue. We relied on the scheduler to dequeue threads from the wakeup queue. But this holds only, if the timeout becomes active. In case of an IPC happening before the timeout expiry, the thread remained in the wakeup queue.
> Scenario: L4/Linux' bottom half thread does IPCs with timeout and with timeout NEVER. If an IPC with a timeout succeeded before the timeout became active, the thread remained in the wakeup queue. Later on, when the thread did an IPC with timeout NEVER, the scheduler found the thread in the wakeup queue with an expired timeout and activated the thread. The thread then concluded, that it woke up due to a timeout and returned with an error code indicating a receive timeout (0x20).
> Solution: put calls to thread_dequeue_wakeup wherever they're required

#### L4/Linux enter_kdebugs "wrong access" after some l4_thread_ex_regs from the signal thread (u)

> Scenario: The signal thread changes the thread's IP to an endless loop in the emulib. Then it installes a faked exception 20 and kicks the thread to the exception handler ... which then returns to the thread.
> Problem: Sometimes the worker thread is in a pagefault IPC. L4/KA does an unwind_ipc by kicking the thread back to user land, but with trashed registers, but the worker thread doesn't know that its registers were trashed.
> Solution: unwind_ipc must not unwind the IPC by placing the thread in userland. It must abort only the IPC operation (i.e., return to the place where do_pagefault_ipc was called), which means that we have to save more state information. :-(

> Would it be enough to save the last_ipc_ksp to the TCB and restore that on an aborted IPC (if it was valid)?
> Late night note: Yes it is. Currently, a return-to-able stack frame is created in do_pagefault_ipc and its location is stored in the TCB (unwind_ipc_sp).

##

2000-04-12

#### l4_thread_schedule doesn't work in RMGR

> sbd. cut the RMGR local c-binding for l4_thread_schedule short
> Having more than one set of syscall bindings is not really healthy!!!

##

2000-04-11

#### L4/Linux spuriously enter_kdebugs "bh error"

> Still looking for the reason of wait(..., IPC_NEVER) returning with timeout

##

2000-04-10

#### L4/Linux sometimes enter_kdebugs "wrong stack" when processes are killed

> Scenario: An L4/Linux task is hit by a signal -> its signal thread receives a message from the L4/Linux kernel. Then it does an lthread_ex_regs on its worker thread (which might be in a pagefault (effectively in an IPC which has to be aborted)).
> In unwind_ipc we called thread_dequeue_send(tcb,tcb) with exchanged arguments. This led to a kernel pagefault by dereferencing a NULL pointer (Maybe, we should add a check for that?), which was turned into an IPC to the corresponding pager -> the L4/Linux kernel. To the L4/Linux kernel this IPC looked like a syscall, but the signal thread must not do Linux syscalls. Finally, the thread_id of the signal thread didn't match the thread_id of the worker thread (stored in L4/Linux' TSS structure) -> L4/Linux complains about the signal thread using the wrong stack (although there is not even a proper stack for that thread anyway :-)

##

2000-01-xx

#### ???

> ...

##

2000-01-18

#### total silence after thread switch

> switching from one thread to another can happen in two ways:

> - switch inside the same address space
> - switch to a different address space

> later is the more interesting and complicated case.
> Following situation:

> Thread A, address space 1 switches to Thread B, address space 2

> assume that the tcb of thread A is not mapped in address space 2. Thus, a
> switch to AS2 *BEFORE* the stack is switched to thread B will cause a
> pagefault on the stack of thread A (since it is not mapped in AS 2). But the
> pagefault handler usually operates on the stack. Therefore, the system hangs
> in an infinite pagefault loop.

> Solution:
> To switch from one address space to another, stacks must be switched BEFORE
> the address space is switched. If a pagefault is raised in the destination
> AS on the source tcb, we already have a valid stack and can handle the
> fault.
> (v)

#### crazy unpredictable behavior when changing small sections in the code (x86)

> probably, GRUB used the memory where the x86-kernel was loaded for its own purpose, after the image was loaded
> short term solution: relocate .init section
> long term solution: sign your code and check signature before execution

##

2000-01-17

#### ???

> ...

##

2000-01-14

#### ???

> ...

##

2000-01-13

#### TCB layout (v)

> Fixed stack size removed

##

2000-01-12

#### IPC (v)

#### Scheduler fixed (v)

#### Flush TLB + Cache (u)

#### ARM Mode switching, used wrong SP (u)

#### Code moved to another section doesn't work any more, but did fine before

> First, even symbols from section `.kdebug` were placed in the `.text` section during the link process.
> When I create a separate `.kdebug` section directly behind the `.text` section, the virtual address of that section is `end(.kdebug)`, as expected.
> I forgot to set the load address of that section, thus is was loaded somewhere but not even near the `.text` section. (u)

## 2000-01-11

#### ???

> ...

##

2000-01-10

#### Cannot raise any exception at all on ARM

> To raise an exception the exception vector must be mapped in the current pagetable. Otherwise, the machine simply locks up. (u)

#### Unplausible values

> When stealing code, always rererererecheck the semantics of type names!!!
> `word_t(source system) != word_t(dest system)`
> (u)

##

## 2000-01-09

#### Make compatibility

> It appears, that make 3.78.1 works better than 3.77... The older version seemed unable to include the Makeconf file, probably caused by a parsing error. Things broke when I started using $(error ... ), I guess. (u)

#### When cpp goes crazy

> like
> `#define blah(x) \`
> `{ \`
> `foo; \`
> `} \`
> being preprocessed as
> `{`
> `foo;`
> `}`
> you might suffer from DOSified files. Emacs not showing `^M` doesn't tell you anything.
> Using cvs under NT with a working directory on a samba share and the repository accessed via rsh does unix2dos and dos2unix translations when checking in/out. Files in working directory contain `^M`. (u)

#### x86-Pagetables

> usermode pagedir entries must have the usermode bit set. (v)

#### VMWare - accessing nonexistent phys mem -> pgfault

> VMWare does not cleanly emulate pagetable entries to non-existing memory. Instead of delivering "undefined" data VMWare raises a pagefault. (v)

#### VMWare uses parts of the virtual mem

> VMWare does not allow full usage of memory beyond 0xFFFF0000. VMWare stops with errors like "muli not emulated". It seems that memory used above that point cannot hold stuff like gdt and idt. (v)

#### TODO

- arch/config.h contains KERNEL_PHYS. This should go into the linker scripts. (u)
- keep in mind: Could we make use of architecturally private TCB members? (u)