In most cases it's safe to abort the requested operation and go forward,
however, in some places it's not clear yet how to handle these failures,
therefore, we use the MUST() wrapper to force a kernel panic for now.
This helps solving an issue when we boot with text mode screen so the
Kernel initializes an early text mode console, but even after disabling
it, that console can still access VGA ports. This wouldn't be a problem
for emulated hardware but bare metal hardware might have a "conflict",
especially if the native driver explicitly request to disable the VGA
emulation.
Instead, hold the lock while we copy the contents to a stack-based
Vector then iterate on it without any locking.
Because we rely on heap allocations, we need to propagate errors back
in case of OOM condition, therefore, both PCI::enumerate API function
and PCI::Access::add_host_controller_and_enumerate_attached_devices use
now a ErrorOr<void> return value to propagate errors. OOM Error can only
occur when enumerating the m_device_identifiers vector under a spinlock
and trying to expand the temporary Vector which will be used locklessly
to actually iterate over the PCI::DeviceIdentifiers objects.
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.
These fences should not be needed, since we force the use of
synchronous operations through synchronous_virtio_gpu_command. The use
of these fences also causes severe lag when SERENITY_GL is enabled.
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.
This additionally refactors FramebufferDevice::try_to_initialize to not
leave the FramebufferDevice in an invalid state on errors.
This also unifies the logic between FramebufferDevice::mmap and
FramebufferDevice::try_to_initialize.
This comes with the drawback of removing the UNMAP_AFTER_INIT attribute
from this function, which wasn't honoured by IntelNativeGraphicsAdapter
anyway.
If there's no PCI bus, then it's safe to assume that the x86 machine we
run on supports VGA text mode console output with an ISA VGA adapter.
If this is the case, we just instantiate a ISAVGAAdapter object that
assumes this situation and allows us to boot into VGA text mode console.
Instead of winging it with "width * 4", use the actual pitch since it
may be different.
This makes the kernel text console show up in native 1368x768 on my
ThinkPad X250. :^)
In short: QEMU supports both Memory-Mapped-IO and classic IO methods
for controlling the emulated VGA device. Bochs and VirtualBox only
support the classic IO method. An excellent write up on the history of
these interfaces can be found here:
https://www.kraxel.org/blog/2018/10/qemu-vga-emulation-and-bochs-display
The IO method was how things were done originally in SerenityOS. Commit
6a728e2d76 introduced the MMIO method for
all devices, breaking Bochs and VirtualBox compatibility. Later in
commit 6a9dc5562d the classic IO method
was restored for VirtualBox graphics adapters.
QEMU and Bochs use the same PCI VID/DID (0x1234/0x1111) for the emulated
VGA adapter. To distinguish betwen QEMU and Bochs we use the PCI
revision ID field (0=Bochs, 2=QEMU).
If the bootloader that loaded us is providing a framebuffer details from
the Multiboot protocol then we can instantiate a framebuffer console.
Otherwise, we should use a text mode console, assuming that the BIOS and
the bootloader didn't try to modeset the screen resolution so we have is
a VGA 80x25 text mode being displayed on screen.
Since "boot_framebuffer_console" is no longer a good representative as a
global variable name, it's changed to g_boot_console to match the fact
that it can be assigned with a text mode console and not framebuffer
console if needed.
Not sure how it's useful to do so, let's not assert if something tries
to disable it. If we will use TextModeConsole as a boot console, that
console will be disabled after loading an appropriate console to replace
it.
Instead, we can construct this type of object without having to
instantiate a VGACompatibleAdapter object first.
This can help instantiate such console very early on boot to aid debug
issues on bare metal hardware.
Function-local `static constexpr` variables can be `constexpr`. This
can reduce memory consumption, binary size, and offer additional
compiler optimizations.
These changes result in a stripped x86_64 kernel binary size reduction
of 592 bytes.
When GraphicsManagement initializes the drivers we can disable the
bootloader framebuffer console. Right now we don't yet fully destroy
the no longer needed console as it may be in use by another CPU.
Instead of seeing a black screen until GraphicsManagement was fully
initialized, this allows us to see the console output much earlier.
So, if the bootloader provided us with a framebuffer, set up a console
as early as possible.
The GenericFramebufferConsoleImpl class implements the logic without
taking into account any other details such as synchronization. The
GenericFramebufferConsole class then is a simple wrapper around
GenericFramebufferConsoleImpl that takes care of synchronization.
This allows us to re-use this implementation with e.g. different
synchronization schemes.
Apologies for the enormous commit, but I don't see a way to split this
up nicely. In the vast majority of cases it's a simple change. A few
extra places can use TRY instead of manual error checking though. :^)
Apparently there was a wrong calculation result when we sent parameters
from TextModeConsole::clear_vga_row method - and we should stick to the
x, y mechanism of the clear method instead of doing the same calculation
which made it to happen twice actually.
This mostly just moved the problem, as a lot of the callers are not
capable of propagating the errors themselves, but it's a step in the
right direction.
We should only look at the framebuffer structure members if the
MULTIBOOT_INFO_FRAMEBUFFER_INFO bit is set in the flags field.
Also add some logging if we ignored the fbdev command line argument
due to either not having a framebuffer provided by the bootloader, or
because we don't support the framebuffer format.
This allows forcing the use of only the framebuffer set up by the
bootloader and skips instantiating devices for any other graphics
cards that may be present.
Previously we would crash the process immediately when a promise
violation was found during a syscall. This is error prone, as we
don't unwind the stack. This means that in certain cases we can
leak resources, like an OwnPtr / RefPtr tracked on the stack. Or
even leak a lock acquired in a ScopeLockLocker.
To remedy this situation we move the promise violation handling to
the syscall handler, right before we return to user space. This
allows the code to follow the normal unwind path, and grantees
there is no longer any cleanup that needs to occur.
The Process::require_promise() and Process::require_no_promises()
functions were modified to return ErrorOr<void> so we enforce that
the errors are always propagated by the caller.
This change lays the foundation for making the require_promise return
an error hand handling the process abort outside of the syscall
implementations, to avoid cases where we would leak resources.
It also has the advantage that it makes removes a gs pointer read
to look up the current thread, then process for every syscall. We
can instead go through the Process this pointer in most cases.
In FB_IOCTL_GET_PROPERTIES we were not initializing the padding of the
struct, leading to the potential of an kernel information leak if the
caller looked back at it's contents.
Lets just be extra paranoid and zero initialize all these structs
in we store on the stack while handling ioctls(..).
This was a premature optimization from the early days of SerenityOS.
The eternal heap was a simple bump pointer allocator over a static
byte array. My original idea was to avoid heap fragmentation and improve
data locality, but both ideas were rooted in cargo culting, not data.
We would reserve 4 MiB at boot and only ended up using ~256 KiB, wasting
the rest.
This patch replaces all kmalloc_eternal() usage by regular kmalloc().
