Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
[SUCCESS] Virtualize Windows 10 for ARM on M1 with Alexander Graf's qemu hypervisor patch
- Thread starter 1958llakin
- Start date
- Sort by reaction score
I updated and relinked libraries, looks like the OP did not compile with same libs as I did, but it should work now.
Or you can just use the GUI wrapper if it is more convenient for you.
Great to see that this is functioning to some degree. These attempts show that it's absolutely possible to virtualize winarm and that it's more of a licensing / will issue. Is USB passthrough functioning or a possibility? There were notes of API calls for such functionality for virtualization
I imagine that on Apple's list of priorities, that is somewhat lower than "build an airstrip for flying pigs" ???
The one reason I find VMs useful is for older lightweight win software and utilities. I have a windows desktop for gaming, but having the ability to use a localised instance of windows on a laptop is useful. You could use an old or cheap win laptop, but lugging everything around would be a headache... But yeah depending on why you would use a VM a seperate device might make more sense
Apple does have a Paravirtualized Graphics framework since Big Sur allowing 3D acceleration in the guest, but the guest driver is only available for macOS. If Apple has no intention to provide guest drivers for alternate OS, we still need to wait for 3rd parties to do it. Parallel's 3D accelerated driver is done by themselves, not Apple.
Not quite. The virtio-gpu they were trying is a virtual GPU provided by RedHat, and Microsoft removed the support for that GPU in a build of Windows(It used to work).
About the frame buffer device, as it saying, it's only a frame buffer. It is implemented in the UEFI firmware we are using, and hopefully if the OS load up a real GPU driver, the UEFI frame buffer will no longer be used and the display will show GPU driver's output. But such driver does not exists in currect Windows build, so the frame buffer is used even Windows is fully loaded. The frame buffer driver is required for nearly all modern desktop operating system, or you will not able to see your screen without a GPU driver is properly installed.
ACVM app works great to get windows arm working.
the only issue is mouse ptr location no synced with system's(macos) ptr location, does it uses usb-tablet or usb-mouse ?
GB5 single score are similar to that on macos
the only issue is mouse ptr location no synced with system's(macos) ptr location, does it uses usb-tablet or usb-mouse ?
GB5 single score are similar to that on macos
QEMU QEMU Virtual Machine - Geekbench
Benchmark results for a QEMU QEMU Virtual Machine with a virt-5.2 processor.
browser.geekbench.com
Last edited:
Yeah, I caught that a second or two after making that post and fixed it immediately. Got a little too excited.
Not sure if that's a serious question, but I am sure most of the people in this thread have access to Windows PC's. That's not the point.
These are the early stages of people tinkering with Windows on ARM based Macs, doing something you're normally not supposed to be able to do due to what's a mix of technical and legal (licensing) hurdles that exist at the moment. Right now, it sounds like it's mostly a legal hurdle. Parallels expressed interest in getting Windows to work in virtualization, and Apple expressed interest in permitting native dual-boot of Windows, but both are contingent on Microsoft allowing that.
A grassroots project like what's going on in this thread could provide an alternative for *both* virtualized and native / dual-boot Windows down the road, even if it's just a stop-gap until something official comes out. Some of the people in here like Netkas are veterans of getting operating systems to run on hardware it was not originally intended for.
I believe virtio-gpu only makes the GPU available to the guest. Still you need a proper Direct3D driver for that GPU.
Similarly the Apple Paravirtualized Graphics Framework. You still need a client driver for the M1 GPU.
In any case Apple certainly could provide such a driver. But agreed, chances are low, that Apple is developing something, what essentially is a Windows Direct3d driver.
Thats what i was implying. What is currently running is a Direct3D driver utilizing the WARP rasterizer which then outputs via DXGI swap chain, which is using the framebuffer provided by UEFI.
Last edited:
Honestly, there's no point to writing a Direct3D driver for Windows 10 on ARM right now. You'll get a very smooth and fast Windows 10 environment that doesn't really run a lot of applications. Your usual CAD suspects won't work well, if at all. For coding work, it's useless when... Docker doesn't work (well, not natively, you can run it in WSL2), Microsoft SQL can't be installed, and hell, a lot of other tools just don't work at all. That's why Microsoft is forced to work on x86-64 emulation. Without it, the Surface Pro X is just a glorified Chromebook.
Windows on ARM suffers from a complete lack of interest both from the users and also from developers. It's the complete opposite of MacOS right now.
Personally, I'm very glad we actually got Ubuntu to work this well. It blows me away completely. Even my 16" MacBook running Ubuntu in VMWare is not this fast!
Windows on ARM suffers from a complete lack of interest both from the users and also from developers. It's the complete opposite of MacOS right now.
Personally, I'm very glad we actually got Ubuntu to work this well. It blows me away completely. Even my 16" MacBook running Ubuntu in VMWare is not this fast!
Technically there are certainly much more 32 bit Windows apps than native apps on Mac and Linux combined - i would not call this "doesn't really run a lot of applications". And again for literally thousands of games, you would like to have accelerated graphics.
Well, that's the issue. You have to have used Windows 10 on ARM first or you would not know this... There are numerous issues with the platform:
1. Many apps that are 32-bit actually may not be compatible with Windows 10. If it's compatible with Windows 10, it may be 64-bit only. This oddly even applies to some of Microsoft's own apps.
2. Even if the apps are compatible with Windows 10, you may run into limitations of the emulation layer itself. Namely... it runs only in user mode and doesn't support Hyper-V. You'd think that should not affect too many apps, but... oddly, it does. Games that rely on anti-cheat, for instance, won't run at all because some anti-cheat measures require drivers. It also goes without saying that your gamepad, printer, favorite PDF editor, antivirus, antimalware, etc... won't work properly, if at all. So the "literally thousands" number is actually much smaller than you may think.
3. Last but not least, it seems the platform is limited to OpenGL 1.1 for whatever reason (we have no idea if this is because of the emulation layer, or because of the Surface Pro X)... so if your game requires newer than that, then you're out of luck. That further scales the number of games you can try further back. This last one means pretty much 90% of modern system emulators (RetroArch, PCSX2, Dolphin, etc...) don't work at all.
Honestly, compatibility with Rosetta 2 is not great. But it works far, far better than whatever Microsoft has for Windows on ARM.
Last edited:
But only a very small portion requires a D3D driver. Most of them will work if we have a proper fake GPU to allow basic resolution settings etc.
It's a good proof of concept. And it's not like it isn't an ARM OS. So, it's definitely doable once licensing is sorted out, at least from the standpoint of virtualization is concerned. I'm still not wholly convinced that the ship has permanently sailed on native booting; though that would require a much greater collaboration between Apple and Microsoft than was necessary for Boot Camp on Intel Macs back in 2006.
Also, given mileage on T2 Macs, I don't believe Apple would open up the Mac to natively booting Linux distros if they opened it up to Microsoft, especially since I think them opening it up to Microsoft isn't really them opening it up as much as them providing the requisite iBoot bootloader for Windows 10 for ARM64.
No, I think the ship has sailed for sure. Making another Boot Camp for Apple Silicon to boot into Windows 10 means Apple will have to also provide arm64 drivers for Windows 10. And on top of all of that, they need to provide drivers for every single one of the processors (like the video encoder/decoder, ML cores, etc...) available on the SoC. That just sounds like a lot of work for no reason at all. Apple isn't even earning anything from the collaboration, and Microsoft at least can sell licenses to their OS.
Virtualization means Apple does not have to directly work with Microsoft on getting Windows 10 to work properly. That task falls on to Parallels and VMWare, and they are already pros at that. Consumers will have to pay Parallels/VMWare/Microsoft if they would like to run Windows 10 for any reason at all, and that sounds like a better model.
Microsoft is the one who has to try and "sell" things to us here, not Apple. Apple has already provided (most) everything.
Virtualization means Apple does not have to directly work with Microsoft on getting Windows 10 to work properly. That task falls on to Parallels and VMWare, and they are already pros at that. Consumers will have to pay Parallels/VMWare/Microsoft if they would like to run Windows 10 for any reason at all, and that sounds like a better model.
Microsoft is the one who has to try and "sell" things to us here, not Apple. Apple has already provided (most) everything.
it won‘t surprise me one little bit if microsoft refuses to make windows for arm available to the public. It’s efforts to promote windows for arm is very poor even if the option was there I would refrain from installing windows for arm on the Mac m1. Who would want to run windows if it crashes all the time? Windows cannot even run on intel machines at all that well even now. Even with virtualisation there is little or no point running windows if it’s going to crash on m1 Systems.
i used to own a iMac 21” and in my experience windows crashed even with bootcamp yes even on intel machines. When I got rid of windows my Mac had less problems much to my relief.
now on my 2 MacBooks I refuse to install windows because of its track record. Not even on the m1 and intel one.
if I were Microsoft I would start again with windows, rewrite it from the ground up make it more stable on arm and intel and making lots of applications compatible with it before releasing windows for arm to the public
I use a Surface Pro X as my daily driver (aside from my MacBook Pro) and there are very few issues with 32 bit x86 apps. Of course drivers as well as most kernel mode stuff could be an issue.
There are apps which are not compatible with Windows 10 in general, but most apps of the last 20 years and even some older do run flawless. I was surprised that even some fairly old apps, like the original Unreal game (from 1998 - the first game which used the unreal engine) does indeed run with Direct3D acceleration.
You can run OpenGL apps up to OpenGL 3.2. There is lots on development going on at the moment - you are possibly not quite up-to-date regarding Windows ARM?
There is no issue with RetroArch or Dolphin even before the availability of OpenGL 3.2 as they support Direct3d12 as backend - as do many other emulators like SNES9x, PCSX, Mame, PPSSPP - which are available in a native ARM64 version under Windows.
Last edited: