Add an option to enable NVMe storage device as the boot
drive.
To enable NVMe support, run the following:
$ SERENITY_NVME_ENABLE=1 Meta/serenity.sh run i686 root=/dev/nvme0n1
I've seen how @awesomekling changes the script to disable KVM, so
that's a useful thing to have.
An example how to use it:
SERENITY_KVM_SUPPORT='0' ./Meta/serenity.sh run x86_64
My first commit btw :^)
Bootmode used to control framebuffers, panic behavior, and SystemServer.
This patch factors framebuffer control into a separate flag.
Note that the combination 'bootmode=self-test fbdev=on' leads to
unexpected behavior, which can only be fixed in a later commit.
This option is similar to the qgrub option, but instead of starting a
QEMU PIIX4 machine, it starts a QEMU Q35 machine, booting a grub image
disk within it.
On my machine (c), /mnt/c/Windows/System32 is not on the PATH by
default. This causes reg.exe to fail, which is responsible for detecting
the presence of QEMU. By putting this path on the PATH on WSL, it will
always work regardless of the specific PATH configuration, and QEMU is
always detected.
This seemed like a good idea at the time to avoid an unnecessary
dependency on qemu-system-i386. However this makes debugging the
kernel with GDB more difficult because GDB assumes that the QEMU
architectures matches the kernel architecture.
As this is a test machine I use personally to test "modern" hardware
setups, it feels quite comfortable to not care too much about VGA with
this type of machine.
Also, we don't actively use the IDE controller on this machine type, so
let's just remove it :^)
This allows one to set their desired parameters for run.sh without the
need to set them in every terminal session or add it to the user account
shell files. If a run-local.sh file exists at the repository root and is
executable, it will be sourced. The file can contain any variables that
are expected to be set in run.sh.
This allows running QEMU inside WSL2 for hosts which have nested KVM
and WSLg support (e.g. Windows 11).
Running QEMU inside the WSL2 VM is slightly slower than running QEMU
on Windows, probably because of how WSLg handles screen updates.
Although it is nice to test the system without too many devices, in
reality bare metal hardware is far more complex than the default skeleon
that QEMU provides. As a preparation of supporting more devices, we
need to ensure we are capable of at least booting on complex hardware
setups without easily-observable problems. Later on, this can be the
foundations of testing new drivers :^)
This gets rid of the following warning message from QEMU on startup:
qemu-system-i386: warning: '-soundhw pcspk' is deprecated, please set a
backend using '-machine pcspk-audiodev=<name>' instead
Fixes#4093.
For users who use a custom kernel with WSL our previous method of
detecting WSL doesn't work. This new check instead detects WSL by
checking if the wslpath utility is available.
Otherwise we're getting this warning:
WARNING: Image format was not specified for '_disk_image' and probing
guessed raw. Automatically detecting the format is dangerous
for raw images, write operations on block 0 will be restricted.
Specify the 'raw' format explicitly to remove the restrictions.
Unfortunately seems like QEMU tries to use SPICE for audio so we need to
explicitly set -audiodev to use either SDL or coreaudio (depending on
platorm)
This implements a simple bootloader that is capable of loading ELF64
kernel images. It does this by using QEMU/GRUB to load the kernel image
from disk and pass it to our bootloader as a Multiboot module.
The bootloader then parses the ELF image and sets it up appropriately.
The kernel's entry point is a C++ function with architecture-native
code.
Co-authored-by: Liav A <liavalb@gmail.com>
If QEMU has the qemu_vdagent chardev (should be present in QEMU 6.1)
then we use that as the SPICE client.
If qemu_vdagent is not present, no SPICE client will be launched by
default because it makes the display a bit choppy.
Set SERENITY_SPICE to override the default behavior and use your default
SPICE client.
Let's remove the qcmd and q35_cmd options and instead have a simple
"q35" run option. Specifiying the kernel command line was a neat trick
I personally used for many debug sessions, but it seems better to stick
to setting it internally in the kernel or modifying the shell
SERENITY_KERNEL_CMDLINE environment variable to do this.
With this change, we use 6 PCIe root ports in the Q35 machine, and plug
the bochs-display device into one of those PCIe ports.
We plug the bochs-display as function 0 of that device, because
otherwise SeaBIOS and also the kernel will not detect its presence.
