This commit adds Processor::set_thread_specific_data, and this function
is used to factor out architecture specific implementation of setting
the thread specific data. This function is implemented for
aarch64 and x86_64, and the callsites are changed to use this function
instead.
This adds the necessary code to init.cpp to be able to execute the first
userspace process. To do this, first the filesystem code is initialized,
which will use the ramdisk embedded into the kernel image. Then the
first userspace process, /bin/SystemServer is executed. :^)
The ramdisk code is used as it is useful for the bring-up of the aarch64
port, however once the kernel has support for better ram-based
filesystems, the ramdisk code will be removed again.
This sets up the correct ThreadRegisters state when a process is
exec'ed, which happens when the first userspace application is executed.
Also changes Processor.cpp to get the stack pointer from the
ThreadRegisters.
This allows the function to be called from other translation units, in
particular this allows the CrashHandler.cpp file to be shared between
aarch64 and x86_64.
Setting the kernel_load_base variable caused backtracking to regress, so
to have proper backtracing the calculation of the symbol address in
KSyms.cpp needs to keep into account that the aarch64 kernel is linked
at a high virtual memory address.
When we execute in userspace, the exception level is EL0, so to handle
exceptions, such as interrupts, and syscalls, we need to add handlers to
vector_table.S. For now we only support running userspace applications
in AArch64 mode, so this commit only adds the handlers for that mode.
To detect instruction aborts, a helper to Registers.h is added, and used
in Interrupts.cpp. Additionally, the PageFault class gets a setter to
set the PageFaults m_is_instruction_fetch bool, and is also used in
Interrupts.cpp.
This patch removes the x86 mechanism for calling syscalls, favoring
the more modern syscall instruction. It also moves architecture
dependent code from functions that are meant to be architecture
agnostic therefore paving the way for adding more architectures.
This will cause page faults to be generated. Since the previous commits
introduced the handling of page faults, we can now actually correctly
handle page faults.
The code in PageDirectory.cpp now keeps track of the registered page
directories, and actually sets the TTBR0_EL1 to the page table base of
the currently executing thread. When context switching, we now also
change the TTBR0_EL1 to the page table base of the thread that we
context switch into.
The handling of page tables is very architecture specific, so belongs
in the Arch directory. Some parts were already architecture-specific,
however this commit moves the rest of the PageDirectory class into the
Arch directory.
While we're here the aarch64/PageDirectory.{h,cpp} files are updated to
be aarch64 specific, by renaming some members and removing x86_64
specific code.
The class used to look at the x86_64 specific exception code to figure
out what kind of page fault happend, however this refactor allows
aarch64 to use the same class.
Various places in the kernel were manually checking the cs register for
x86_64, however to share this with aarch64 a function in RegisterState
is added, and the call-sites are updated. While we're here the
PreviousMode enum is renamed to ExecutionMode.
Until now the kernel was always executing with SP_EL0, as this made the
initial dropping to EL1 a bit easier. This commit changes this behaviour
to use the corresponding SP_ELx for each exception level.
To make sure that the execution of the C++ code can continue, the
current stack pointer is copied into the corresponding SP_ELx just
before dropping an exception level.
There are now 2 separate classes for almost the same object type:
- EnumerableDeviceIdentifier, which is used in the enumeration code for
all PCI host controller classes. This is allowed to be moved and
copied, as it doesn't support ref-counting.
- DeviceIdentifier, which inherits from EnumerableDeviceIdentifier. This
class uses ref-counting, and is not allowed to be copied. It has a
spinlock member in its structure to allow safely executing complicated
IO sequences on a PCI device and its space configuration.
There's a static method that allows a quick conversion from
EnumerableDeviceIdentifier to DeviceIdentifier while creating a
NonnullRefPtr out of it.
The reason for doing this is for the sake of integrity and reliablity of
the system in 2 places:
- Ensure that "complicated" tasks that rely on manipulating PCI device
registers are done in a safe manner. For example, determining a PCI
BAR space size requires multiple read and writes to the same register,
and if another CPU tries to do something else with our selected
register, then the result will be a catastrophe.
- Allow the PCI API to have a united form around a shared object which
actually holds much more data than the PCI::Address structure. This is
fundamental if we want to do certain types of optimizations, and be
able to support more features of the PCI bus in the foreseeable
future.
This patch already has several implications:
- All PCI::Device(s) hold a reference to a DeviceIdentifier structure
being given originally from the PCI::Access singleton. This means that
all instances of DeviceIdentifier structures are located in one place,
and all references are pointing to that location. This ensures that
locking the operation spinlock will take effect in all the appropriate
places.
- We no longer support adding PCI host controllers and then immediately
allow for enumerating it with a lambda function. It was found that
this method is extremely broken and too much complicated to work
reliably with the new paradigm being introduced in this patch. This
means that for Volume Management Devices (Intel VMD devices), we
simply first enumerate the PCI bus for such devices in the storage
code, and if we find a device, we attach it in the PCI::Access method
which will scan for devices behind that bridge and will add new
DeviceIdentifier(s) objects to its internal Vector. Afterwards, we
just continue as usual with scanning for actual storage controllers,
so we will find a corresponding NVMe controllers if there were any
behind that VMD bridge.
