summaryrefslogtreecommitdiff
path: root/Kernel/Graphics/VirtIOGPU/GPU3DDevice.cpp
AgeCommit message (Collapse)Author
2023-06-04Kernel: Move Random.{h,cpp} code to Security subdirectoryLiav A
2023-04-24Kernel: Improve context state keeping in the VirtIOGPU3DDevice classLiav A
This is done mainly by implementing safe locking on the data structure keeping the pointers to the PerContextState objects. Therefore, this now eliminates the need for using LockRefPtr, as SpinlockProtected is enough for the whole list. The usage of HashMap in this class was questionable, and according to Sahan Fernando (the original contributor to the VirGL work also known as ccapitalK) there was no deep research on which data structure to use for keeping all pointers to PerContextState objects. Therefore, this structure is changed to IntrusiveList as the main reason and advantage to use it is that handling OOM conditions is much more simple, because if we succeeded to create a PerContextState object, we can be sure now that inserting it to the list will not cause OOM error condition.
2023-02-23Kernel: Prevent out-of-bounds read/write in VirtIO GPU3DDevice::ioctlLiav A
Before doing a check if offset_in_region + num_bytes of the transfer descriptor are together more than NUM_TRANSFER_REGION_PAGES * PAGE_SIZE, check that addition of both of these parameters will not simply overflow which could lead to out-of-bounds read/write. Fixes #17518.
2023-01-21Kernel+Userland: Move LibC/sys/ioctl_numbers to Kernel/API/Ioctl.hAndrew Kaster
This header has always been fundamentally a Kernel API file. Move it where it belongs. Include it directly in Kernel files, and make Userland applications include it via sys/ioctl.h rather than directly.
2022-12-19Kernel/Graphics: Propagate errors properly around in the VirtIO driverLiav A
This happens to be a sad truth for the VirtIOGPU driver - it lacked any error propagation measures and generally relied on clunky assumptions that most operations with the GPU device are infallible, although in reality much of them could fail, so we do need to handle errors. To fix this, synchronous GPU commands no longer rely on the wait queue mechanism anymore, so instead we introduce a timeout-based mechanism, similar to how other Kernel drivers use a polling based mechanism with the assumption that hardware could get stuck in an error state and we could abort gracefully. Then, we change most of the VirtIOGraphicsAdapter methods to propagate errors properly to the original callers, to ensure that if a synchronous GPU command failed, either the Kernel or userspace could do something meaningful about this situation.
2022-12-19Kernel: Properly propagate errors in VirtIOGPU 3D device initializationLiav A
2022-12-15Kernel: Allocate VirtIOGPU context IDs from a bitmap, with ErrorOrSam Atkins
As is, we never *deallocate* them, so we will run out eventually. Creating a context, or allocating a context ID, now returns ErrorOr if there are no available free context IDs. `number_of_fixmes--;` :^)
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-07-12Everywhere: Add sv suffix to strings relying on StringView(char const*)sin-ack
Each of these strings would previously rely on StringView's char const* constructor overload, which would call __builtin_strlen on the string. Since we now have operator ""sv, we can replace these with much simpler versions. This opens the door to being able to remove StringView(char const*). No functional changes.
2022-05-05Kernel/Graphics: Apply DisplayConnector design on the VirtIO driverLiav A
2022-05-05Kernel/Graphics: Use VirtIO GPU3DDevice constructor indirectlyLiav A
We shouldn't expose the VirtIO GPU3DDevice constructor as public method, so instead, let's use the usual pattern of a static construction method that uses the constructor within the method.
2022-03-18Kernel: Fix crash when opening GPU3DDevice without creating a contextSahan Fernando
2022-03-14Kernel: Fix buffer overflow in VirtIOGPU create_3d_resource(..)Brian Gianforcaro
This code attempts to copy the `Protocol::Resource3DSpecification` struct into request, starting at `Protocol::ResourceCreate3D::target` member of the `Protocol::ResourceCreate3D` struct. The problem is that the `Protocol::Resource3DSpecification` struct does not having the trailing `u32 padding` that the `ResourceCreate3D` struct has. Leading to memcopy overrunning the struct and corrupting 32 bits of data trailing the struct. Found by SonarCloud: - Memory copy function overflows the destination buffer.
2022-03-14Kernel: Sandbox each GPU3DDevice file description into own host contextSahan Fernando
2022-03-09Kernel: Implement basic VirGL deviceSahan Fernando
This commit flips VirtIOGPU back to using a Mutex for its operation lock (instead of a spinlock). This is necessary for avoiding a few system hangs when queuing actions on the driver from multiple processes, which becomes much more of an issue when using VirGL from multiple userspace process. This does result in a few code paths where we inevitably have to grab a mutex from inside a spinlock, the only way to fix both issues is to move to issuing asynchronous virtio gpu commands.