Boot SerenityOS

[copy]

Pretty cool hobby OS: https://github.com/SerenityOS/serenity

Requires hardware task switching support: https://github.com/SerenityOS/serenity/blob/7fc903b/Kernel/Scheduler.cpp#L574-L578

[copy]

Serenity seems to have removed (most uses of) hardware tasking in SerenityOS/serenity@fb41d89. Next blocker: PAE (#97)

[copy]

This is now working (except for newer versions, which are likely affected by #597): https://copy.sh/v86/?profile=serenity

[copy]

(cc @pwmarcz, thanks for the info in #599 (comment))

I fixed an ACPI bug in v86 (it was not being applied). Now running into SerenityOS/serenity#11980 (even with ACPI on in v86). Will wait on a fix on their side and then look into the IDE and graphics issues.

[supercomputer7]

SerenityOS/serenity#11980 is closed as it was resolved.
I'm working on support for the QEMU ISA-PC machine type for SerenityOS:
SerenityOS/serenity#12046
I don't know in what state this project is in right now, just thought it might help you somehow :)

[copy]

After the ACPI bugfixes we're running into "ASSERTION FAILED: !m_storage_devices.is_empty()". It looks like a bug in v86's pci code, which I'm investigating. A Serenity build with legacy ISA port access would probably work too.

[copy]

Seems to be three separate issues (with enable_ioapic=off acpi=off):

• v86 doesn't map the IO ports for the IDE controller correctly (they are mapped by seabios to some high port, but v86 only handles the legacy locations). This needs to be fixed on our side.
• Serenity accesses the IDE control port at bar1 with offset 0. v86 maps it at bar1 with offset 2 (same port in a legacy configuration: 0x3f6). I suspect Serenity's behaviour is correct, but I will need to confirm that.
• Lastly, v86 doesn't support configuring graphics registers (Bochs VBE extensions) through memory-mapped IO. Serenity does support access through port IO, but only enables it if the virtualbox graphics adapter is detected. Probably fairly easy to fix on either side.

I have reasonable workarounds for the latter two issues, but the first one will need some work. After that the latest version of Serenity works in v86.

[supercomputer7]

Seems to be three separate issues (with enable_ioapic=off acpi=off):

* v86 doesn't map the IO ports for the IDE controller correctly (they are mapped by seabios to some high port, but v86 only handles the legacy locations). This needs to be fixed on our side.

* Serenity accesses the IDE control port at bar1 with offset 0. v86 maps it at bar1 with offset 2 (same port in a legacy configuration: 0x3f6). I suspect Serenity's behaviour is correct, but I will need to confirm that.

* Lastly, v86 doesn't support configuring graphics registers ([Bochs VBE extensions](https://wiki.osdev.org/Bochs_VBE_Extensions)) through memory-mapped IO. Serenity does support access through port IO, but only enables it if the virtualbox graphics adapter is detected. Probably fairly easy to fix on either side.

I have reasonable workarounds for the latter two issues, but the first one will need some work. After that the latest version of Serenity works in v86.

As for issue number 3:
Well, for Serenity you could easily fake a VirtualBox graphics adapter and be done with it. I'd argue to not add a kernel commandline option to force Serenity to use IO ports as we talk about virtualized hardware and it seems to me like a better workaround can be achieved. We also can support legacy Bochs graphics adapters but honestly, I don't think it worth anybody time to do that, and instead implementing memory mapped registers seems like the cleanest solution for this problem :)

[copy]

I fixed the aforementioned issues. SerenityOS now conveniently checks the PCI revision to see if mmio is available, which v86 incorrectly advertised as available. It seems there have been other fixes on the serenity side, because enable_ioapic=off acpi=off isn't necessary any more, so serenity master now works without patches on v86.

I've updated to the latest version: http://copy.sh/v86/?profile=serenity

The only outstanding issue is that networking doesn't work with the public relay at relay.widgetry.org. It works fine when running a local relay. I can see the outgoing dhcp packets from serenity as well as incoming packets from unrelated traffic on the relay. There is no response to the dhcp packets that serenity sends out, so either those are dropped by the relay, or their responses are not correctly delivered.

Gently pinging @benjamincburns in case he's aware of any difference between the public relay and the one in the repository.

I've added some network packet logging to https://copy.sh/v86/debug.html, if anybody wants to have a look.

[benjamincburns]

I'm not aware of any differences that would break things on your end, but happy to help look into it. I'll have a poke tomorrow.

[benjamincburns]

Is it only a problem under SerenityOS?

[copy]

Yes, I've only seen this issue happen with SerenityOS.

I made a testcase without the emulator by copying the initial dhcp packet from serenity and udhcpcd, and sending it to the online relay and a local one: http://copy.sh/testcase-serenity-relay.html

Commenting out either //const packet = packet_udhcpcd; or //const ws = new WebSocket("ws://127.0.0.1:8080/"); results in receiving a reply from the dhcp server, e.g.:

receive len=342 ethertype=0x800 ipv4.len=328 ipv4.proto=0x11 udp.srcport=67 udp.dstport=68 udp.chksum=0xE70A dhcp.chaddr=00:22:15:78:3d:b4

[benjamincburns]

Apologies, I got a bit distracted with work things and I wasn't able to look into this until now.

How are you running the local relay? If you aren't using the docker image, perhaps you could give that a try?

[benjamincburns]

Got it sorted. I'm not entirely certain what specifically was going wrong, but I bumped the Dockerfile to use Ubuntu Jammy, and it seems to be working now. I suspect SerenityOS is using some DHCP protocol feature that the 6-year-old dnsmasq version that I had running on the public relay couldn't support.

[benjamincburns]

Unfortunately the fix mentioned above introduced a regression in the public relay and had to be temporarily rolled back. I don't have an ETA on a fix yet, but please watch benjamincburns/websockproxy#10 for updates.

[benjamincburns]

And we're back

[copy]

@benjamincburns Brilliant, cheers!

To summarize: The latest version of Serenity works, without patches, including networking, and loads much faster (#710).

Enjoy! https://copy.sh/v86/?profile=serenity