run.sh builds i686 by default, and the aarch64 port of serenity
isn't very far along yet.
Without this change, `run.sh` without arguments unceremoniously
fails with:
[0/1] cd .../serenity/Build/i686 && /usr...
ENITY_ARCH=i686 /home/thakis/src/serenity/Meta/run.sh
qemu-system-i386: invalid accelerator kvm
That's because /dev/kvm exists, but that's no good on a non-intel host.
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.
The microvm machine type is a modern tool for kernel and firmware
developers to test their software against features like FDTs, second
IOAPIC, lack of legacy devices by default, the ability of using PCIe
without using PCI x86 IO ports, etc.
We can boot into such machine but we are limited in the functionality we
support currently for this type of virtual machine.
The ISA-PC machine type provides no PCI bus support, no IOAPIC support
and other modern PC features of our generation.
This is mainly a good environment for testing abstractions in the kernel
space, and can help with improving on them for the sake of porting the
OS to other chipsets and CPU architectures.
Previously we added it only if spice was available, but it's possible to
build qemu with --disable-spice --enable-spice-protocol, which provides
qemu-vdagent but no spicevmc. In such case we still configured
qemu-vdagent to use "vdagent" device, but never actually defined it, so
the qemu-vdagent was never working.
QEMU crashes on M1 Macs when using `--accel hvf` option.
To solve this, detect the host's architecture and only add the
`--accel hvf` parameter if we are running on a "x86_64" machine.
This will allow "arm64" machines like M1 Macs to work correctly.
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)
