M1 ARM Macs: Will Virtualbox be ported ?

Discussions related to using VirtualBox on Mac OS X hosts.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: ARM Macs: Will Virtualbox be ported ?

Post by mpack »

multiOS wrote:
macandroid wrote:So how do VMware and Parallels [do] this on an M1 Mac ?
They don't!
But I'm sure they'll be quite happy to part a sucker from his cash anyway... :twisted:

Seriously folks, I've heard companies make many ridiculous announcements over the years. It's called vaporware. Wake me up when it's real.
Dimitrisv
Posts: 17
Joined: 3. Sep 2020, 17:50

Re: ARM Macs: Will Virtualbox be ported ?

Post by Dimitrisv »

mpack wrote:What I said is absolutely, fully true. Wishing otherwise will have no effect. Sure, you can do an ARM hypervisor, but who does that help?

And in any case: an ARM hypervisor would have to be developed from scratch. It's not a port of VirtualBox.
Thank you for the clarifications! Although I would have loved to try the ARM way (its architect Steve Furber was my teacher at the University in my undergrad years), I decided that it is too early. Possibly, it will take at least a few years for ARM to mature - because indeed does make sense due to its energy consumption.

Until then, as we have work to do, I will go for ASUS RAG G14 with Ryzen 9 4900HS and NVIDIA's 2060 to run those CUDA projects I was unable to run in my MacbookPro. Actually, the Ryzen 9, 4900 is much faster than Silicon M1 - but that apple marketing got the best of me (they are claiming the x2 improvement vs. their own Intel processors).


Cheers!
Last edited by scottgus1 on 20. Nov 2020, 21:02, edited 2 times in total.
Reason: removed offsite link
gertmenkel
Posts: 1
Joined: 23. Nov 2020, 03:25
Primary OS: Linux other
VBox Version: OSE other
Guest OSses: Windows, Linux

Re: ARM Macs: Will Virtualbox be ported ?

Post by gertmenkel »

Alright, now I'm curious. I know x86 or x86_64 won't run natively or accelerated on ARM (can't leverage Rosetta2 with a hypervisor) but what is preventing VB from being implemented for ARM? Hypervisors are available on AS, as per Apple's documentation page (see the link from the earlies post, click "Apple Silicon" at the bottom) , booting ARM64 Linux or Windows through UEFI already works, drivers and virtual device implementations already exist in the form of VirtIO (which VirtualBox already support (partially?) anyway) and Microsoft is actively changing Windows to run well on existing ARM64 hypervisors.

I know, translating the necessary processor optimizations will be hard and will take a while if Oracle ever considers it, but if the alternative is "nobody buys support for Oracle's product on Macs from now on", the investment might just be worth it. It's up to Oracle to put work into VirtualBox to make it work, but there's nothing preventing them from doing so.

On a technical level, the KVM hypervisor has already been implemented on ARM64 (although there is no official Red Hat support because the code isn't finished yet as of right now). Regardless, there are various source on the internet explaining how to enable KVM on the Raspberry Pi 3, so architecturally there is nothing that's preventing a hypervisor from running on any modern ARM chip. Aarch64 support on KVM does NOT use binary translation and runs just as quick as the host OS thanks to the virtualisation instruction set in ARM64m that has its analogue in released versions of Apple SIlicon (the dev kit did not have them but the M1 does). With KVM being open source, Oracle could probably reuse a lot of the existing KVM code for their port if their implementation is still lacking certain features.

What software will VB be able to run? Well, Linux for one; developers often use Linux virtual machine to run Docker containers on operating systems like Windows or macOS. Armbian should run just fine on AS because it runs fine on basically anything ARM-based right now.

Windows also has a publicly available early build for ARM64, so you can actually theoretically run Windows in VB on an M1 with native speed, provided that drivers are made available. Windows on ARM uses UEFI, just like on x64, so that's something that can be easily ported. Linux also has an ARM64 UEFI bootloader and VB already implements UEFI support so the boot sequence isn't a problem. The PCIe spec isn't dependent on x86 either, so several of the existing drivers could just be recompiled to make them work with Windows on ARM64. If that doesn't work, Oracle can implement more VirtIO emulation for things like network, IO, RNG, serial ports, and graphics, because open source drivers for those virtualised devices already exist in a working fashion (the KVM guest drivers for both Windows and Linux have ARM64 support).

Actual PC emulators (like QEMU) have already been shown to run ARM versions of Windows. The Raspberry Pi has already been shown to run ARM Windows. You don't have to be a PC emulator to make virtualised hardware work on ARM64 because that's a problem the KVM folks have already solved, for free, together with Microsoft who has been patching Windows to work with ARM hypervisors so their OS works on ARM chips in data centres.

Will you be able to run Photoshop from your Windows guest as fast as it runs on the M1? No, of course not, not until Adobe releases an ARM build for Windows and even then it'll be slower than Rosetta2 or native ARM. However, any dotNET application or Windows Store application will probably be able to run just fine and theoretically you might even be able to use Microsoft's version of Rosetta2, which they've developed together with Qualcomm, to run x86 (not x64) based Windows applications, as long as they don't use OpenGL. The MS Surface X has proven that doing this on ARM is possible, as limited as the device is in practice; Microsoft clearly has some work to do before they join Apple in releasing ARM devices.

I would not recommend anyone using their computer for educational or professional use to buy bleeding edge hardware because of the inherent instability and lack of support at release. However, as far as I know, there's no technical reason why VirtualBox can't be ported to ARM; it's purely a financial decision as it takes time and money to port a hypervisor and Oracle might not see their investment back any time soon. Competitors of Oracle like Parallels have already stated that they are working on ARM virtual machine platforms. The M1 launched only recently and the devkits did not implement the right instructions so of course there's not software products out yet; the work on them has only just started. I see no reason to call ARM hypervisors "vaporware" because there's absolutely nothing preventing such software from working other than the work that needs to be put into porting the necessary optimizations.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: ARM Macs: Will Virtualbox be ported ?

Post by mpack »

I see no point in endlessly repeating myself for those too lazy to read the discussion: which would not be so long if it was not for the constant repetition.

For the last time: porting to a CPU was never the problem.
FritzS
Posts: 51
Joined: 27. Feb 2019, 11:10
Primary OS: Mac OS X other
VBox Version: OSE other
Guest OSses: Windows, Linux, BSD
Location: Austria

Re: ARM Macs: Will Virtualbox be ported ?

Post by FritzS »

macandroid wrote:I don't mean a CPU emulator, but VB running natively on ARM, so it can obviously only run ARM guests, so ARM Windows or ARM Linux (and even Android), which are already available.
I don't expect an ARM Virtualbox running X86 guests as it is not an emulator.
No Intel emulator planned?
Looks like as Paralles will do?
Nice greetings
Fritz
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: ARM Macs: Will Virtualbox be ported ?

Post by mpack »

More repetition. The difference between a CPU hypervisor and a CPU simulator has already been covered, and is anyway irrelevant in the context of the question asked (see the topic title).

Locking this since we have had nothing but repetition for too long now.
Locked