To do so, we now check that the framebuffer type is RGB so we know that
the Multiboot bootloader actually provided a valid framebuffer to work
with.
This fixes a problem I observed on my ICH7 test machine that apparently
the multiboot_framebuffer_addr was not null but there was no framebuffer
that was set up for RGB colors, and by initializing that console, there
was a memory curroption caused somewhere in the EBDA area to probably
cause a complete system lockup.
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.
This class already has variables named m_lock, and it's also strange
that locals are named with the `m_` prefix. So lets fix that to make
the code more readable.
Found by PVS-Studio.
C++20 provides the `requires` clause which simplifies the ability to
limit overload resolution. Prefer it over `EnableIf`
With all uses of `EnableIf` being removed, also remove the
implementation so future devs are not tempted.
Since the allocated memory is going to be zeroed immediately anyway,
let's avoid redundantly scrubbing it with MALLOC_SCRUB_BYTE just before
that.
The latest versions of gcc and Clang can automatically do this malloc +
memset -> calloc optimization, but I've seen a couple of places where it
failed to be done.
This commit also adds a naive kcalloc function to the kernel that
doesn't (yet) eliminate the redundancy like the userland does.
This is mainly useful when adding an HostController but due to OOM
condition, we abort temporary Vector insertion of a DeviceIdentifier
and then exit the iteration loop to report back the error if occured.
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.
As there is no need for a Prekernel on aarch64, the Prekernel code was
moved into Kernel itself. The functionality remains the same.
SERENITY_KERNEL_AND_INITRD in run.sh specifies a kernel and an inital
ramdisk to be used by the emulator. This is needed because aarch64
does not need a Prekernel and the other ones do.
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.
The project appears to build just fine without it, and the explicit use
of `LibC` causes it to conflict with the system-wide `fd_set.h` when
building inside of Serenity.
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 init crashes, all other userspace processes exit too, thus rendering
the system unusable. Previously, the kernel would still keep running
even without a userland, showing just a black screen without any
indication of the issue.
We now panic the kernel, which shows a message on the console. In the
case of the CI runners, it shuts down the virtual machine, so we don't
have to wait for the 1 hour timeout if an issue arises with
SystemServer.
The stack is misaligned at this point for some reason, this is a hack
that makes the resulting object "correctly" aligned, thus avoiding a
KUBSAN error.
Mere mortals like myself cannot understand more than two lines of
assembly without a million comments explaining what's happening, so do
that and make sure no one has to go on a wild stack state chase when
hacking on these.
The comments were confusing, and had a mathematical error, stop trying
to be clever and just let the computer do the math.
Also assert that we're pushing exactly as many stack elements as we're
using for the alignment calculations.
POSIX requires that sigaction() and friends set a _process-wide_ signal
handler, so move signal handlers and flags inside Process.
This also fixes a "pid/tid confusion" FIXME, as we can now send the
signal to the process and let that decide which thread should get the
signal (which is the thread with tid==pid, but that's now the Process's
problem).
Note that each thread still retains its signal mask, as that is local to
each thread.
Previously register_string would return incorrect values when
called multiple times with the same input. This patch makes this
function return the same index, identical strings. This change was
required, as this functionality is now being used with read syscall
profiling, (#12465), which uses 'register_string' to registers file
path on every read syscall.
If there's no PCI bus, then it's safe to assume that we run on a x86
machine that has an ISA IDE controller in the system. In such case, we
just instantiate a ISAIDEController object that assumes fixed locations
of IDE IO ports.
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.
Reading from /proc/pci assumes we have PCI enabled and also enumerated.
However, if PCI is disabled for some reason, we can't allow the user to
read from it as there's no valuable data we can supply.
To declare that we don't have a PCI bus in the system we do two things:
1. Probe IO ports before enabling access -
In case we are using the QEMU ISA-PC machine type, IO probing results in
floating bus condition (returning 0xFF values), thus, we know we don't
have PCI bus on the system.
2. Allow the user to specify to not use the PCI bus at all in the kernel
commandline.
This change allow the user to request the kernel to not use any PCI
resources/devices at all.
Also, don't try to initialize devices that rely on PCI if disabled.
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. :^)
We now only reset the PCM out channel during initialization, and handle
the case where the channel's current index has passed the last valid
index properly.
This fixes issues with stuttering audio between multiple subsequent
`aplay` invocations, for example.
This might help with debugging on bare metal. Since the minimum version
that can be specified is revision 2.1, and we do not use any feature
from revision 2.2 or newer, this is merely future-proofing ourselves
for new features yet to be built. Additionally, removing the `VERIFY()`
ensures we will not crash on cards that only support earlier revisions.
These are not technically required, since the Thread constructor
already sets these, but they are set on i686, so let's try and keep
consistent behaviour between the different archs.
The Qemu AC'97 device stops its PCM channel's DMA engine when it is
running and the sample rate is changed. We now make sure the DMA engine
is restarted after changing the sample rate, allowing you to e.g. run
`asctl set r 22050` during `aplay` playback.
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).
This driver is not tested and probably not used on any modern hardware
machine, because it is plugged into the ISA bus and not the PCI bus.
Also, the run script doesn't utilize this device anymore, making it more
hard to test this driver and to ensure it doesn't rot.
