[Bug]: Black screen on Windows 11 ARM64 when using VBoxSVGA or VMWSVGA

[jernejs]

Version

trunk/main

Host OS Type

Windows

Host OS name + version

Windows 11 24H2 26100.4946

Host Architecture

ARM

Guest OS Type

Windows

Guest Architecture

ARM

Guest OS name + version

Windows 10 22H2

Component

Other

What happened?

Hardware: Microsoft Volterra (Dev Kit 2023)

VirtualBox most of the time fails to display anything on screen unless QemuRamFB is selected as display adapter. Problem appears both with 7.2.0 and 7.2.1 r170274. Very rarely VBoxSvga works (only managed it once with 7.2.0 and once with 7.2.1), in which case resizing of guest display works without problems. QemuRamFB works every time.

I know that Windows 10 is not officially supported as a guest, but the problem also happens with a completely fresh VM, with nothing installed inside.

blackscreen.log
working.log

How can we reproduce this?

Create a new VM, leave display adapter set to VBoxSvga, start it

Did you upload all of your necessary log files, screenshots, etc.?

• Yes, I've uploaded all pertinent files to this issue.

[jernejs]

Some more info: with 7.2.1 VBoxSVGA starts working after installing the guest (it's still broken for new VMs), though 3D acceleration is quite broken, both for Windows 10 and 11.

[TBOpen]

For non-arm system (x64), I have to use MSVGA or I just get a black screen, never get the virtualbox logo or a post. But then the extensions in Win11 don't resize the screen.

[moreaki]

This looks potentially related to the ARMv8 VMSVGA VRAM/MMIO part of #742 / #743.

I compared the two logs attached here:

• blackscreen.log uses VRamSize = 0x10000000 / 256 MiB and shows the ARMv8 32-bit PCI MMIO window as 0xe0000000..0xefffffff.
• working.log uses VRamSize = 0x08000000 / 128 MiB with the same 32-bit PCI MMIO window, and reaches normal Display::i_handleDisplayResize activity.

#743 expands the ARMv8 PCI 32-bit MMIO layout so 256 MiB VMSVGA VRAM leaves room for the VMSVGA3 MMIO BAR. Although the validation in #742 was on a macOS/Arm host, the attached logs here suggest the same 256 MiB VMSVGA/ARMv8 MMIO sizing problem may be involved in this Windows/Arm-host case as well.

I am not claiming this covers all VBoxSVGA/VMWSVGA black-screen cases or the separate 3D instability reports, but it may address the 256 MiB VMSVGA black-screen subcase.