Project overview
QEMU is a virtual machine which allows running an operating system inside of another. While there already is a Haiku port, it currently does not support any acceleration system through native virtualization (through Intel VT-x and AMD SVM.) This makes it too slow for many uses.
This project aimed to bring hardware virtualization to Haiku by porting NVMM, a hypervisor that already has QEMU support, into Haiku from DragonFlyBSD. The project goals (as included on the proposal) were:
The goal of this document is to be an overview of everything I did during GSoC. It should be readable even if you haven’t read any of the previous blog posts and don’t know much about Haiku or WebKit (I hope I succeeded!).
First, some background. Haiku’s native browser is WebPositive.
WebPositive’s code mostly deals with the user interface. It uses our fork of WebKit, HaikuWebKit, to actually render the web pages, run JavaScript, process input, and so on. WebKit (and, by extension, HaikuWebKit) provides two API versions: WebKitLegacy, and WebKit (aka WebKit2). Unfortunately, we are still stuck using WebKitLegacy even though WebKit2 has been out for more than a decade.
Project overview
A part of Google Summer of Code 2024, this project aimed to improve the userland debugging
experience for Haiku app developers, boosting the process of building and porting complex
applications.
The first objective was to have a working build of a modern version of GDB running on Haiku
x86_64 - the most popular architecture with stable Haiku. Using some ideas from the incomplete
recipe
for GDB 8.1, I have ported GDB 15.1 to Haiku from the ground up.
So I’ve implemented mouse support. It also turned out to be really easy to fix text rendering. So, what’s next? Well, some websites like https://discuss.haiku-os.org cause WebKit to crash. This crash also seems to affect other websites. Really, it seems to occur anytime WebKit decides to use multiple bitmaps (actually, in WebKit lingo, backing stores) to render a web page. Rendering a single bitmap is easy, just display it! But when you have multiple, you need to composite them together. It seems like WebKit currently requires EGL and maybe OpenGL to do this.
This report covers hrev57802 through hrev57900.
Project status overview
Completed tasks
The goal of this phase was to stabilize GDB, making it suitable for debugging complex and
multi-threaded applications (including most Be API applications).
After clearing the first round of bug reports, the first revision of the GDB package is now online
on HaikuPorts.
When attempting to use the published package to work on Debugger, I found a second round of bugs,
resulting in the pending second revision of
the port. This version of GDB is now stable enough to attach to and debug a copy of itself.
intro
Hello, once again!
vid?
We made it! I previously stated that we had achieved playback,
but I never got to show it. So here it is, a short video
showing you that playback actually works.
So you don’t have to go and compile it, just to see it on
action.
outro
Main functionality is here! So, I believe that it may be
time to maybe push into the main branch.
Success! Now MiniBrowser displays things once again. Here is MiniBrowser showing https://review.haiku-os.org/
So, yeah, there’s still plenty of work left to do. Text isn’t rendered properly, keyboard and mouse support is missing, the window can’t be resized without MiniBrowser crashing, and it crashes when exited. I’ll take it one step at a time. Let’s make the mouse work! Then I can actually click on stuff. I think implementing that will be straightforward.
Project status overview
Completed tasks
The GDB port is feature-complete. A recipe has been submitted to HaikuPorts.
This took a bit longer than expected due to complexities in building the full GDB compared to
gdbserver - all of which will be covered in the technical details section
below. Subtle bugs revealed by invoking the debugger in different use cases delayed the project
even more.
Despite being off schedule, I believe delivering a fully-functional GDB along with comprehensive
documentation around it would benefit the community much more in the long run.
intro
Hello, once again! It’s been weeks since the last update, so here we go.
Good news, there is active development of the virtio sound driver for Haiku.
Key progress includes recording on the device and improvements.
buffer exchange redesign
As per the last blog post:
We still specify 2 playback buffers, but incremented to 16,384 frames per
buffer, to handle audio streams.
struct multi_buffer_info {
// [...]
bigtime_t played_real_time;
bigtime_t played_frames_count;
// [...]
int32 playback_buffer_cycle;
bigtime_t recorded_real_time;
bigtime_t recorded_frames_count;
// [...]
int32 record_buffer_cycle;
// [...]
};
I messed up a lot during these last two weeks. A certain bug
appeared, and it was a tricky one, not even appearing all the time. As far
as I’m concerned, it looks like I should not have gone playback-first and
recording-last.
