feat: Bochs VBE linear framebuffer support

[GloriousAlpaca]

I'm currently working on porting Doom to Hermit and needed a feature to directly write pixel data into the Bochs Graphics Adaptor as Hermit currently only has support for VGA in textmode.

The feature currently adds standard BGA preparation (Link to OSDev) with a hardcoded resolution (640x400), bpp (32) and a systemcall (sys_get_framebuffer) to receive the address of the framebuffer.
The systemcall falls back to 0 if there was a failure in initializing the framebuffer (e.g. if pci is missing, or the bga feature is not enabled).

I have currently only tested this feature with c programs on a mac using Qemu. The feature is also only available on the x86_64 architecture.

[github-actions]

Benchmark Results

Details

Benchmark	Current: 52e245a	Previous: 2e23902	Performance Ratio
startup_benchmark Build Time	93.32 s	80.34 s	1.16 ❗
startup_benchmark File Size	0.78 MB	0.80 MB	0.98 ❗
Startup Time - 1 core	0.71 s (±0.02 s)	0.75 s (±0.02 s)	0.95 ❗
Startup Time - 2 cores	0.71 s (±0.02 s)	0.74 s (±0.02 s)	0.97
Startup Time - 4 cores	0.73 s (±0.02 s)	0.74 s (±0.02 s)	0.98
multithreaded_benchmark Build Time	91.58 s	82.11 s	1.12 ❗
multithreaded_benchmark File Size	0.85 MB	0.86 MB	0.99 ❗
Multithreaded Pi Efficiency - 2 Threads	64.41 % (±6.37 %)	85.89 % (±6.61 %)	0.75 ❗
Multithreaded Pi Efficiency - 4 Threads	40.49 % (±2.17 %)	43.43 % (±2.56 %)	0.93
Multithreaded Pi Efficiency - 8 Threads	20.04 % (±1.30 %)	25.76 % (±1.53 %)	0.78 ❗
micro_benchmarks Build Time	218.64 s	80.40 s	2.72 ❗
micro_benchmarks File Size	0.85 MB	0.86 MB	0.99 ❗
Scheduling time - 1 thread	170.76 ticks (±32.32 ticks)	62.65 ticks (±4.06 ticks)	2.73 ❗
Scheduling time - 2 threads	94.44 ticks (±20.13 ticks)	34.08 ticks (±4.10 ticks)	2.77 ❗
Micro - Time for syscall (getpid)	8.58 ticks (±4.91 ticks)	3.45 ticks (±0.58 ticks)	2.49 ❗
Memcpy speed - (built_in) block size 4096	60735.27 MByte/s (±42315.03 MByte/s)	82448.38 MByte/s (±56997.13 MByte/s)	0.74
Memcpy speed - (built_in) block size 1048576	13915.16 MByte/s (±11691.93 MByte/s)	30585.98 MByte/s (±24707.84 MByte/s)	0.45
Memcpy speed - (built_in) block size 16777216	12435.25 MByte/s (±10336.67 MByte/s)	26340.06 MByte/s (±21720.96 MByte/s)	0.47
Memset speed - (built_in) block size 4096	60703.82 MByte/s (±42291.20 MByte/s)	82292.76 MByte/s (±56891.50 MByte/s)	0.74
Memset speed - (built_in) block size 1048576	14264.57 MByte/s (±11893.82 MByte/s)	31323.85 MByte/s (±25145.86 MByte/s)	0.46
Memset speed - (built_in) block size 16777216	12683.21 MByte/s (±10450.40 MByte/s)	27104.68 MByte/s (±22209.94 MByte/s)	0.47
Memcpy speed - (rust) block size 4096	52137.34 MByte/s (±37007.47 MByte/s)	74097.96 MByte/s (±51811.44 MByte/s)	0.70
Memcpy speed - (rust) block size 1048576	14182.13 MByte/s (±11806.52 MByte/s)	30361.60 MByte/s (±24602.37 MByte/s)	0.47
Memcpy speed - (rust) block size 16777216	12455.63 MByte/s (±10373.87 MByte/s)	27625.34 MByte/s (±22806.88 MByte/s)	0.45
Memset speed - (rust) block size 4096	52428.25 MByte/s (±37197.78 MByte/s)	74373.47 MByte/s (±51976.48 MByte/s)	0.70
Memset speed - (rust) block size 1048576	14482.09 MByte/s (±11960.50 MByte/s)	31110.89 MByte/s (±25033.24 MByte/s)	0.47
Memset speed - (rust) block size 16777216	12691.24 MByte/s (±10484.20 MByte/s)	28386.93 MByte/s (±23265.03 MByte/s)	0.45
alloc_benchmarks Build Time	208.71 s	74.76 s	2.79 ❗
alloc_benchmarks File Size	0.86 MB	0.87 MB	0.98 ❗
Allocations - Allocation success	91.38 %	91.31 %	1.00 ❗
Allocations - Deallocation success	100.00 %	100.00 %	1
Allocations - Pre-fail Allocations	61.60 %	61.44 %	1.00 ❗
Allocations - Average Allocation time	24536.50 Ticks (±1395.72 Ticks)	5860.58 Ticks (±98.43 Ticks)	4.19 ❗
Allocations - Average Allocation time (no fail)	25812.94 Ticks (±1823.13 Ticks)	6554.81 Ticks (±92.86 Ticks)	3.94 ❗
Allocations - Average Deallocation time	8104.52 Ticks (±1718.51 Ticks)	1805.01 Ticks (±250.35 Ticks)	4.49 ❗
mutex_benchmark Build Time	208.98 s	79.82 s	2.62 ❗
mutex_benchmark File Size	0.85 MB	0.86 MB	0.99 ❗
Mutex Stress Test Average Time per Iteration - 1 Threads	36.86 ns (±6.87 ns)	12.10 ns (±0.41 ns)	3.05 ❗
Mutex Stress Test Average Time per Iteration - 2 Threads	32.62 ns (±9.93 ns)	40.26 ns (±1.68 ns)	0.81

This comment was automatically generated by workflow using github-action-benchmark.

[mkroening]

Thanks for the PR! :)

This is great! First I was wondering why we should use BGA instead of UEFI's GOP, which would also work on real machines, but I guess BGA is just easier at the moment. Since it is not that invasive, this is fine with me.

I am a bit confused regarding naming; maybe you could clear that up in a doc comment of the module or even the feature documentation. If I understand correctly, BGA is the Bochs Graphics Adapter, which we talk to via the VESA BIOS Extensions (VBE) API. But instead of talking to the BIOS via interrupts, we can just talk to the VBE API through the special BGA ports, right? In that case, the module names, feature names, and constant names make sense to me now.

[mkroening]

Ah, please also ensure that your PR does not include merge commits. Please rebase instead.

[GloriousAlpaca]

Thanks a lot for the feedback! I have pushed a commit, where I've addressed the feedback you've given. I have actually implemented the systemcall a bit differently than I've written before. Please do have a look if this is a good way to design it. I have also used structs instead of enums to consolidate the constants. Let me know if this is alright with you.

[github-actions]

LLM review

The BGA driver implementation has several critical issues that need to be addressed, particularly around unsafe operations, error handling, and potential race conditions.

[jounathaen]

Suggested change

	#[cfg(feature = "bga")]
	#[cfg(all(target_arch = "x86_64", feature = "bga"))]

[jounathaen]

This is not thread safe, as two parallel invocations could cause a race.

Instead: Make these functions a member function of BgaRegisters that takes a &mut reference. The struct itself should be put into a OnceCell with a Mutex.

Then you can add a corresponding safety comment as well 😉