summaryrefslogtreecommitdiff
path: root/Kernel/Bus
AgeCommit message (Collapse)Author
2023-03-08Kernel/VirtIO: Ignore Configurations that have length of zero bytesLiav A
These configurations are simply invalid. Ignoring those allow us to boot with the virtio-gpu-pci device (in addition to the already supported virtio-vga PCI device).
2023-03-07Kernel: Use non-locking {Nonnull,}RefPtr for OpenFileDescriptionAndreas Kling
This patch switches away from {Nonnull,}LockRefPtr to the non-locking smart pointers throughout the kernel. I've looked at the handful of places where these were being persisted and I don't see any race situations. Note that the process file descriptor table (Process::m_fds) was already guarded via MutexProtected.
2023-03-06Kernel: Stop using NonnullLockRefPtrVectorAndreas Kling
2023-03-06Everywhere: Remove NonnullOwnPtr.h includesAndreas Kling
2023-03-06Everywhere: Stop using NonnullOwnPtrVectorAndreas Kling
Same as NonnullRefPtrVector: weird semantics, questionable benefits.
2023-03-06Everywhere: Remove NonnullRefPtr.h includesAndreas Kling
2023-03-06Everywhere: Stop using NonnullRefPtrVectorAndreas Kling
This class had slightly confusing semantics and the added weirdness doesn't seem worth it just so we can say "." instead of "->" when iterating over a vector of NNRPs. This patch replaces NonnullRefPtrVector<T> with Vector<NNRP<T>>.
2023-02-24Kernel/FileSystem: Simplify the ProcFS significantlyLiav A
Since the ProcFS doesn't hold many global objects within it, the need for a fully-structured design of backing components and a registry like with the SysFS is no longer true. To acommodate this, let's remove all backing store and components of the ProcFS, so now it resembles what we had in the early days of ProcFS in the project - a mostly-static filesystem, with very small amount of kmalloc allocations needed. We still use the inode index mechanism to understand the role of each inode, but this is done in a much "static"ier way than before.
2023-02-21Kernel: Fix const-correctness of PCI::DeviceIdentifier usageAndreas Kling
2023-02-10Everywhere: Remove needless copies of Error / ErrorOr instancesTimothy Flynn
Either take the underlying objects with release_* methods or move() the instances around.
2023-01-28AK: Remove `try_` prefix from FixedArray creation functionsLinus Groh
2023-01-27Kernel: Remove declarations for non-existent methodsSam Atkins
2023-01-26Kernel/PCI: Expose PCI option ROM data from the sysfs interfaceLiav A
For each exposed PCI device in sysfs, there's a new node called "rom" and by reading it, it exposes the raw data of a PCI option ROM blob to a user for examining the blob.
2023-01-26Kernel/PCI: Hold a reference to DeviceIdentifier in the Device classLiav A
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.
2023-01-21Everywhere: Remove string.h include from AK/Traits.h and resolve falloutAndrew Kaster
A lot of places were relying on AK/Traits.h to give it strnlen, memcmp, memcpy and other related declarations. In the quest to remove inclusion of LibC headers from Kernel files, deal with all the fallout of this included-everywhere header including less things.
2023-01-13AK: Add support for "debug only" formattersMacDue
These are formatters that can only be used with debug print functions, such as dbgln(). Currently this is limited to Formatter<ErrorOr<T>>. With this you can still debug log ErrorOr values (good for debugging), but trying to use them in any String::formatted() call will fail (which prevents .to_string() errors with the new failable strings being ignored). You make a formatter debug only by adding a constexpr method like: static constexpr bool is_debug_only() { return true; }
2023-01-05Kernel: Add dmesgln_pci logging for Kernel::PCIEvan Smal
A virtual method named device_name() was added to Kernel::PCI to support logging the PCI::Device name and address using dmesgln_pci. Previously, PCI::Device did not store the device name. All devices inheriting from PCI::Device now use dmesgln_pci where they previously used dmesgln.
2023-01-02Kernel: Turn lock ranks into template parameterskleines Filmröllchen
This step would ideally not have been necessary (increases amount of refactoring and templates necessary, which in turn increases build times), but it gives us a couple of nice properties: - SpinlockProtected inside Singleton (a very common combination) can now obtain any lock rank just via the template parameter. It was not previously possible to do this with SingletonInstanceCreator magic. - SpinlockProtected's lock rank is now mandatory; this is the majority of cases and allows us to see where we're still missing proper ranks. - The type already informs us what lock rank a lock has, which aids code readability and (possibly, if gdb cooperates) lock mismatch debugging. - The rank of a lock can no longer be dynamic, which is not something we wanted in the first place (or made use of). Locks randomly changing their rank sounds like a disaster waiting to happen. - In some places, we might be able to statically check that locks are taken in the right order (with the right lock rank checking implementation) as rank information is fully statically known. This refactoring even more exposes the fact that Mutex has no lock rank capabilites, which is not fixed here.
2022-12-28Kernel: Reorganize Arch/x86 directory to Arch/x86_64 after i686 removalLiav A
No functional change.
2022-12-28Kernel: Remove i686 supportLiav A
2022-12-22AK: Rename Bitmap::try_create() to ::create()Sam Atkins
This is step 1 to removing `must_create()`.
2022-12-09Kernel: Allow opening some device nodes sparingly for jailed processesLiav A
From now on, we don't allow jailed processes to open all device nodes in /dev, but only allow jailed processes to open /dev/full, /dev/zero, /dev/null, and various TTY and PTY devices (and not including virtual consoles) so we basically restrict applications to what they can do when they are in jail. The motivation for this type of restriction is to ensure that even if a remote code execution occurred, the damage that can be done is very small. We also don't restrict reading and writing on device nodes that were already opened, because that limit seems not useful, especially in the case where we do want to provide an OpenFileDescription to such device but nothing further than that.
2022-11-18Kernel: Fix includes when building aarch64Steffen Rusitschka
This patch fixes some include problems on aarch64. aarch64 is still currently broken but this will get us back to the underlying problem of FloatExtractor.
2022-11-12Kernel/USB: Use proper verbs for Pipe transfer methodsb14ckcat
2022-11-12Kernel/USB: Add support for async & interrupt transfersb14ckcat
Add support for async transfers by using a separate kernel task to poll a list of active async transfers on a set time interval, and invoke their user-provided callback function when they are complete. Also add support for the interrupt class of transfers, building off of this async functionality.
2022-11-08Kernel: Split the SysFS core files into smaller componentsLiav A
2022-10-26Kernel: Include missing headers for various filesTimon Kruiper
With these missing header files, we can now build these files for aarch64.
2022-10-22Kernel+USB: Move descriptor bookkeeping into seperate structure(s)Jesse Buhagiar
We now have a seperately allocated structure for the bookkeeping information in the QueueHead and TransferDescriptor UHCI strucutres. This way, we can support 64-bit pointers in UHCI, fixing a problem where 32-bit pointers would truncate the upper 32-bits of the (virtual) address of the descriptor, causing a crash. Co-authored-by: b14ckcat <b14ckcat@protonmail.com>
2022-10-18Kernel/USB: Refactor USB Pipeb14ckcat
Decompose the current monolithic USBD Pipe interface into several subclasses, one for each pair of endpoint type & direction. This is to make it more clear what data and functionality belongs to which Pipe type, and prevent nonsensical things like trying to execute a control transfer on a non-control pipe. This is important, because the Pipe class is the interface by which USB device drivers will interact with the HCD, so the clearer and more explicit this interface is the better.
2022-10-18Kernel/USB: Adjust USB Pipe bufferb14ckcat
Allocate DMA buffer pages for use within the USBD Pipe class, and allow for the user to specify the size of this buffer, rounding up to the next page boundary.
2022-09-30Kernel: Fix a comment typoNico Weber
2022-09-23Kernel: Introduce the IOWindow classLiav A
This class is intended to replace all IOAddress usages in the Kernel codebase altogether. The idea is to ensure IO can be done in arch-specific manner that is determined mostly in compile-time, but to still be able to use most of the Kernel code in non-x86 builds. Specific devices that rely on x86-specific IO instructions are already placed in the Arch/x86 directory and are omitted for non-x86 builds. The reason this works so well is the fact that x86 IO space acts in a similar fashion to the traditional memory space being available in most CPU architectures - the x86 IO space is essentially just an array of bytes like the physical memory address space, but requires x86 IO instructions to load and store data. Therefore, many devices allow host software to interact with the hardware registers in both ways, with a noticeable trend even in the modern x86 hardware to move away from the old x86 IO space to exclusively using memory-mapped IO. Therefore, the IOWindow class encapsulates both methods for x86 builds. The idea is to allow PCI devices to be used in either way in x86 builds, so when trying to map an IOWindow on a PCI BAR, the Kernel will try to find the proper method being declared with the PCI BAR flags. For old PCI hardware on non-x86 builds this might turn into a problem as we can't use port mapped IO, so the Kernel will gracefully fail with ENOTSUP error code if that's the case, as there's really nothing we can do within such case. For general IO, the read{8,16,32} and write{8,16,32} methods are available as a convenient API for other places in the Kernel. There are simply no direct 64-bit IO API methods yet, as it's not needed right now and is not considered to be Arch-agnostic too - the x86 IO space doesn't support generating 64 bit cycle on IO bus and instead requires two 2 32-bit accesses. If for whatever reason it appears to be necessary to do IO in such manner, it could probably be added with some neat tricks to do so. It is recommended to use Memory::TypedMapping struct if direct 64 bit IO is actually needed.
2022-09-20Kernel/Graphics: Introduce support for QEMU isa-vga deviceLiav A
This device is supposed to be used in microvm and ISA-PC machine types, and we assume that if we are able to probe for the QEMU BGA version of 0xB0C5, then we have an existing ISA Bochs VGA adapter to utilize. To ensure we don't instantiate the driver for non isa-vga devices, we try to ensure that PCI is disabled because hardware IO test probe failed so we can be sure that we use this special handling code only in the QEMU microvm and ISA-PC machine types. Unfortunately, this means that if for some reason the isa-vga device is attached for the i440FX or Q35 machine types, we simply are not able to drive the device in such setups at all. To determine the amount of VRAM being available, we read VBE register at offset 0xA. That register holds the amount of VRAM divided by 64K, so we need to multiply the value in our code to use the actual VRAM size value again. The isa-vga device requires us to hardcode the framebuffer physical address to 0xE0000000, and that address is not expected to change in the future as many other projects rely on the isa-vga framebuffer to be present at that physical memory address.
2022-09-20Kernel/PCI: Convert PCI BAR number to a strong typed enum classLiav A
2022-09-20Kernel: Remove stale includes of x86 IO header fileLiav A
The AHCI code doesn't rely on x86 IO at all as it only uses memory mapped IO so we can simply remove the header. We also simply don't use x86 IO in the Intel graphics driver, so we can simply remove the include of the x86 IO header there too. Everything else was a bunch of stale includes to the x86 IO header and are actually not necessary, so let's remove them to make it easier to compile non-x86 Kernel builds.
2022-09-20Kernel: Move PCI initialization x86-specific code to the arch directoryLiav A
It seems more correct to let each platform to define its own sequence of initialization of the PCI bus, so let's remove the #if flags and just put the entire Initializer.cpp file in the appropriate code directory.
2022-09-20Kernel/PCI: Move IO based HostBridge code to x86 arch-specific directoryLiav A
The simple PCI::HostBridge class implements access to the PCI configuration space by using x86 IO instructions. Therefore, it should be put in the Arch/x86/PCI directory so it can be easily omitted for non-x86 builds.
2022-09-20Kernel: Move IO delay code to x86 architecture subdirectoryLiav A
Many code patterns and hardware procedures rely on reliable delay in the microseconds granularity, and since they are using such delays which are valid cases, but should not rely on x86 specific code, we allow to determine in compile time the proper platform-specific code to use to invoke such delays.
2022-09-20Kernel/PCI: Don't use x86 initialization methods in non-x86 buildsLiav A
Using the IO address space is only relevant for x86 machines, so let's not compile instructions to access the PCI configuration space when we don't target x86 platforms.
2022-09-17Kernel/USB: Hotplug multiple USB device crash hotfixb14ckcat
2022-08-28Kernel/USB: Rework UHCI interrupt transfer scheduleb14ckcat
This reworks the way the UHCI schedule is set up to handle interrupt transfers, creating 11 queue heads each assigned a different period/latency, so that interrupt transfers can be linked into the schedule with their specified period more easily.
2022-08-28Kernel/USB: Rework queued transfer scheduleb14ckcat
Modifies the way the UHCI schedule is set up & modified to allow for multiple transfers of the same type, from one or more devices, to be queued up and handled simultaneously.
2022-08-20Kernel: Make self-contained locking smart pointers their own classesAndreas Kling
Until now, our kernel has reimplemented a number of AK classes to provide automatic internal locking: - RefPtr - NonnullRefPtr - WeakPtr - Weakable This patch renames the Kernel classes so that they can coexist with the original AK classes: - RefPtr => LockRefPtr - NonnullRefPtr => NonnullLockRefPtr - WeakPtr => LockWeakPtr - Weakable => LockWeakable The goal here is to eventually get rid of the Lock* classes in favor of using external locking.
2022-08-20AK+Kernel: Add AK::AtomicRefCounted and use everywhere in the kernelAndreas Kling
Instead of having two separate implementations of AK::RefCounted, one for userspace and one for kernelspace, there is now RefCounted and AtomicRefCounted.
2022-08-19Kernel: Require lock rank for Spinlock constructionkleines Filmröllchen
All users which relied on the default constructor use a None lock rank for now. This will make it easier to in the future remove LockRank and actually annotate the ranks by searching for None.
2022-07-30Kernel: Remove PCI information node from ProcFSLiav A
The SystemMonitor program was the last client to utilize this node, and now it is not using this node anymore, we can simply remove this for good.
2022-07-27Kernel: Fix USB hotplug crashb14ckcat
Currently the SysFS node for USB devices is only initialized for USB hubs, which means it will cause a kernel crash upon being dereferenced in a non-hub device. This fixes the problem by making initialization happen for all USB devices.
2022-07-22Everywhere: Prefix 'TYPEDEF_DISTINCT_ORDERED_ID' with 'AK_'Linus Groh
2022-07-19Kernel/USB: Make UHCI descriptor pool thread-safeb14ckcat
Right now the TD and QH descriptor pools look to be susceptible to a race condition in the event they are accessed simultaneously by separate threads making USB transfers. This fix does not seem to add any noticeable overhead.
2022-07-15Kernel/SysFS: Adapt USB plug code to work with SysFS patternsLiav A