Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

per-cpu TSSs / GDT #418

Open
todo bot opened this issue Aug 12, 2019 · 0 comments
Open

per-cpu TSSs / GDT #418

todo bot opened this issue Aug 12, 2019 · 0 comments
Assignees
Labels
project-kernel Related to the kernel safety Something is unsound, could be unsafe todo 🗒️ Created by the todo bot

Comments

@todo
Copy link

todo bot commented Aug 12, 2019

There are multiple things that aren't ideal about the way we handle TSSs.

Initialization

TSSs must always be initialized with an iopb_offset of `size_of::<TSS>()`, so that the TSS's data is not interpreted as the iopb.
However, because MAIN_TASK has a huge iopb (0x2001 bytes), we want it to live in the .bss, and be lazy initialized (iopb_offset value, and iopb array memset to 0xFF). `lazy_static` seems appropriate for that, and we should use it, so we cannot forget to initialize a TSS.
DOUBLE_FAULT_TASK could be statically initialized, except for the `cr3` field.

Per-cpu

But we will likely want a MAIN and DOUBLE_FAULT TSS per core. However, they cannot trivially be put behind a `#[thread_local]`, as they are initialized with the GDT, before cpu-locals are initialized. It might be possible to make them `#[thread_local]` with some post-initialization routine that switches to using the MAIN and DOUBLE_FAULT_TASK in the cpu-local memory area instead of the static early one, after cpu-local have been initialized, for core 0. The static early one could do without an iopb, since we're not going to userspace with it.
For other cores, having a `#[thead_local]` inside a `lazy_static!` seems to work, but I don't yet know how cores are going to be started, whether they allocate/initialize their own GDT + MAIN + DOUBLE_FAULT TSS, if it their parent core do it.
Because of these unknowns, the search for a good design for TSSs/GDT is postponed.

Locking

Since the TSSs are supposed to be cpu-local, there is no reason for them to have a mutex around them. An ideal design would be lock-less, which can either be achieved with `#[thread_local]`, or some custom wrapper around an UnsafeCell just for TSSs.

DOUBLE_FAULT's cr3

The DOUBLE_FAULT TSS(s)'s cr3 must point to a valid page directory, which will remain valid (i.e. not be freed) for the entire lifetime of the kernel, and possibly updated when kernel page tables are modified.
For now, because we have no such hierarchy, we always make DOUBLE_FAULT's cr3 point to the current cr3, and update it when we switch page table hierarchies. However the current way we do kernel paging is not viable for SMP, and we might finally implement such a hierarchy for SMP, we could then make DOUBLE_FAULT TSS(s) point to it.


// TODO: per-cpu TSSs / GDT
// BODY: There are multiple things that aren't ideal about the way we handle TSSs.
// BODY:
// BODY: ## Initialization
// BODY:
// BODY: TSSs must always be initialized with an iopb_offset of `size_of::<TSS>()`,
// BODY: so that the TSS's data is not interpreted as the iopb.
// BODY:
// BODY: However, because MAIN_TASK has a huge iopb (0x2001 bytes), we want it to live in the
// BODY: .bss, and be lazy initialized (iopb_offset value, and iopb array memset to 0xFF).
// BODY: `lazy_static` seems appropriate for that, and we should use it, so we cannot *forget* to


This issue was generated by todo based on a TODO comment in 7333eaf when #415 was merged. cc @Orycterope.
@todo todo bot added the todo 🗒️ Created by the todo bot label Aug 12, 2019
@roblabla roblabla added project-kernel Related to the kernel safety Something is unsound, could be unsafe labels Aug 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
project-kernel Related to the kernel safety Something is unsound, could be unsafe todo 🗒️ Created by the todo bot
Projects
None yet
Development

No branches or pull requests

2 participants