[SUCCESS] Virtualize Windows 10 for ARM on M1 with Alexander Graf's qemu hypervisor patch

[Susurs]

Ok, so I got the driver signed with a test certificate I created. The below assumes you've already allowed TESTSIGN to enable the ethernet driver.

When you expand the archive, there are a few files:

ACVM.cer - this is the test cert, and will need to be added to the Windows Trust Store
viogpudo.* - various driver files.
InstallCerts and Driver.bat - This is a bat file I created which should show a UAC prompt, then install the cert into the Windows Trust Store, and then install the driver.

If you open the BAT file, you can see the last few lines to see what the command does, if you'd rather do the install manually.

After this is done, you should be able to shutdown Windows. Then in AVCM, switch the graphics option to from ramfb to virtio-gpu:

View attachment 1697613

If you leave the "unhide mouse pointer" checked, then you will see the Mac cursor and it avoids the invisible cursor issue that @Gnattu discovered. Alternatively, you can switch the cursor option in Windows to use the Black cursor instead of the White cursor, and then uncheck the "unhide mouse pointer" in ACVM, and you will be using and see the black Windows cursor.

Let me know if you run into any install issues with this. It was my first time doing windows driver signing.

Thank you! It’s working.

When I set the display to fullscreen in higher resolution / or FHD, the borders of the screen go over my mac’s internal screen so only part of the picture is visible. Is there a way to set some HiDPI resolution setting or something?

 

[kupan787]

Thank you! It’s working.

When I set the display to fullscreen in higher resolution / or FHD, the borders of the screen go over my mac’s internal screen so only part of the picture is visible. Is there a way to set some HiDPI resolution setting or something?

So it looks like the driver hardcodes the list of display options that it will make available:

In the file viogpudo.cpp

GPU_DISP_MODE gpu_disp_modes[] =
{
    {1024, 768, VGPU_BPP},
    {1280, 1024, VGPU_BPP},
    {1920, 1080, VGPU_BPP},
    {2560, 1600, VGPU_BPP},
};

I updated this code and added a few more options:

    {1280, 800, VGPU_BPP},
    {1440, 900, VGPU_BPP},
    {1680, 1050, VGPU_BPP},

This won't fix the HiDPI stuff, but it should allow you to properly set a full screen resolution that will match to a resolution you have selected on the Mac. I tested this on my install, and the new options appear. And when I set the display to 1440x900, and enable Full Screen, it fills my monitor completely.

 

[Susurs]

So it looks like the driver hardcodes the list of display options that it will make available:

In the file viogpudo.cpp

GPU_DISP_MODE gpu_disp_modes[] =
{
    {1024, 768, VGPU_BPP},
    {1280, 1024, VGPU_BPP},
    {1920, 1080, VGPU_BPP},
    {2560, 1600, VGPU_BPP},
};

I updated this code and added a few more options:

    {1280, 800, VGPU_BPP},
    {1440, 900, VGPU_BPP},
    {1680, 1050, VGPU_BPP},

This won't fix the HiDPI stuff, but it should allow you to properly set a full screen resolution that will match to a resolution you have selected on the Mac. I tested this on my install, and the new options appear. And when I set the display to 1440x900, and enable Full Screen, it fills my monitor completely.

Excellent! Thank you a lot!

 

[kupan787]

ACVM or QEMU can run virtual nic at brideg mode?

qemu can do bridge networking, but it makes use of the tun/tap functionality.

I don't believe there is currently a tun/tap functionality for M1 currently, so I believe we are limited to the default QEMU Networking.

 

[Gnattu]

qemu can do bridge networking, but it makes use of the tun/tap functionality.

I don't believe there is currently a tun/tap functionality for M1 currently, so I believe we are limited to the default QEMU Networking.

Million dollar question: how does Parallel managed to create bridged network without using a kernel extension?

 

[kupan787]

Interesting, I haven’t really explored Parallels yet. Could they be making use of Apples Networking Extension framework?

 

[shal]

qemu can do bridge networking, but it makes use of the tun/tap functionality.

I don't believe there is currently a tun/tap functionality for M1 currently, so I believe we are limited to the default QEMU Networking.

i try other vm project (vftool) by default is using the bridge mode

but i using vftool is install ubuntu only this is can ssh my main host & ping any ip address
this project networking is com.apple.vm.networking
it appears to be kernel-level NAT from a bridged interface instead of the user-level TCP/IP stuff as used in QEMU

i think ACVM project is can try use this framework

 

[Spikeee]

Correction you can extend it. You can also disable caching in Device manager.

How did you do this Nate? I've extended my disk using qemu resize but it doesn't give me any option in disk management to extend the partition as there's a recovery partition straight after it.
Trying to boot the Gparted iso just fails everytime.
I was using this one. gparted-live-1.1.0-8-amd64.iso
Is there another one I should use ?

 

[Gnattu]

i try other vm project (vftool) by default is using the bridge mode

but i using vftool is install ubuntu only this is can ssh my main host & ping any ip address
this project networking is com.apple.vm.networking
it appears to be kernel-level NAT from a bridged interface instead of the user-level TCP/IP stuff as used in QEMU

i think ACVM project is can try use this framework

The bridged mode is quite new, just introduced in Catalina.

 

[haralds]

So it looks like the driver hardcodes the list of display options that it will make available:

In the file viogpudo.cpp

GPU_DISP_MODE gpu_disp_modes[] =
{
    {1024, 768, VGPU_BPP},
    {1280, 1024, VGPU_BPP},
    {1920, 1080, VGPU_BPP},
    {2560, 1600, VGPU_BPP},
};

I updated this code and added a few more options:

    {1280, 800, VGPU_BPP},
    {1440, 900, VGPU_BPP},
    {1680, 1050, VGPU_BPP},

This won't fix the HiDPI stuff, but it should allow you to properly set a full screen resolution that will match to a resolution you have selected on the Mac. I tested this on my install, and the new options appear. And when I set the display to 1440x900, and enable Full Screen, it fills my monitor completely.

This works well. Just a hint: turn back to "ramfb" before doing Windows Updates or you lose the screen. Then turn it all back on.

 

[Valiran]

Hello, i'm still locked with this error when I boot the iso made with UUP: 0xC06D007F.
What I've done is just download the last ACVM 1.5 and create a new VM (and create a new disk file)
What am I doing wrong?
Please help
I'm on a MBP 8GB for info

 

[kupan787]

Hello, i'm still locked with this error when I boot the iso made with UUP: 0xC06D007F.
What I've done is just download the last ACVM 1.5 and create a new VM (and create a new disk file)
What am I doing wrong?
Please help
I'm on a MBP 8GB for info

For me, I wasn't able to boot from the ISO I made with UUP. I had also tried with the VHDK to sign in to my Microsoft account, and setup the Insider Builds, but I wasn't able (kept giving an error).

Finally what I did was I used the VHDK, converted it to qcow2. Then I mounted the ISO in Windows, but didn't boot from it. From within Windows, I navigated to the CD and ran setup. I made sure to remove the options to check for updates. I let that go, and it installed newer version, and things are working (mostly) fine now.

I still have internet issues from time to time (sometimes Windows sees I am connected, sometimes not), but Edge seems to always work. Also, I still can't connect to my Microsoft Account, Store doesn't work, etc. But I can run x86 and x64 apps. I was even able to install all components needed to run Visual Studio 2019, and build the virtio-gpu driver.

So by no means a simple process. It took me some effort to get up and running.

 

[yawns]

Has anyone been able to get non-Ubuntu linux running? I have Ubuntu running, but that was pretty easy because it ships as a single arm-based iso you can pass to QEMU and boot from. Seems like non-Debian distros only provide hardware-specific tarballs that are supposed to be extracted to an SSD. I tried creating a disk image with qemu-img ("raw" type), mounting, formatting, and extracting a "pi3" tar to it; but QEMU still wouldn't boot it (I tried different "rasp3" and "virt" machine types). I'm totally new to both arm and QEMU, so if anyone could provide steps/hints on getting one of these to work with QEMU I'd appreciate it.

 

[Gnattu]

Has anyone been able to get non-Ubuntu linux running? I have Ubuntu running, but that was pretty easy because it ships as a single arm-based iso you can pass to QEMU and boot from. Seems like non-Debian distros only provide hardware-specific tarballs that are supposed to be extracted to an SSD. I tried creating a disk image with qemu-img ("raw" type), mounting, formatting, and extracting a "pi3" tar to it; but QEMU still wouldn't boot it (I tried different "rasp3" and "virt" machine types). I'm totally new to both arm and QEMU, so if anyone could provide steps/hints on getting one of these to work with QEMU I'd appreciate it.

If you are referring to Arch Linux, you have to use the generic tar all and set the boot configs including mkinitcpio and fstab and kernel boot args by yourself like what you are doing a normal arch installation on an x86 computer. You can use a distorted with direct bootable iso like Ubuntu, or raw disk file like fedora, then install arch-chroot on it then chroot to your extracted disk to perform the installation. If you managed to install arch linux by yourself you know what to do after chroot.

 

[kupan787]

i try other vm project (vftool) by default is using the bridge mode

but i using vftool is install ubuntu only this is can ssh my main host & ping any ip address
this project networking is com.apple.vm.networking
it appears to be kernel-level NAT from a bridged interface instead of the user-level TCP/IP stuff as used in QEMU

i think ACVM project is can try use this framework

Unfortunately it is not so simple.

First, ACVM is just a GUI frontend/wrapper for qemu. All of the networking is handled by qemu. So in order to take advantage of the networking frameworks, it would need to be changes to qemu itself. There isn't anything that we can do in ACVM to change the networking.

Second, according to the documentation for vftool:

The bridging requires the binary to have the com.apple.vm.networking entitlement, and Apple docs helpfully give this note:

Note This entitlement is restricted to developers of virtualization software. To request this entitlement, contact your Apple representative.

This seems to be saying that one requires a paid developer account and to ask nicely to be able to use this OS feature.

Fortunately, the "NAT" default works fine for the outgoing direction, and even permits incoming connections -- it appears to be kernel-level NAT from a bridged interface instead of the user-level TCP/IP stuff as used in QEMU

So it doesn't appear that Vftool is doing bridging in the true sense, but is still doing NAT. It is just better NAT than QEMU's version.

 

[Gnattu]

Unfortunately it is not so simple.

First, ACVM is just a GUI frontend/wrapper for qemu. All of the networking is handled by qemu. So in order to take advantage of the networking frameworks, it would need to be changes to qemu itself. There isn't anything that we can do in ACVM to change the networking.

Second, according to the documentation for vftool:



So it doesn't appear that Vftool is doing bridging in the true sense, but is still doing NAT. It is just better NAT than QEMU's version.

The entitlement to use it is not assigned to vftools because the developer does not have the required certificate, but vftools does implement the feature, if you have a developer certificate with the entitlement, you can sign it and use that.

 

[Gnattu]

Double checked. Parallels does have the vm.networking entitlement to use the bridged interface provided by the kernel.
We are limited to user-space NAT of qemu until someone want to ask apple nicely for the entitlement.

 

[jdb8167]

View attachment 1699458

Double checked. Parallels does have the vm.networking entitlement to use the bridged interface provided by the kernel.
We are limited to user-space NAT of qemu until someone want to ask apple nicely for the entitlement.

I think a developer from QEmu needs to do that. Maybe ask Alexander Graf?

 

[Gnattu]

I think a developer from QEmu needs to do that. Maybe ask Alexander Graf?

The developer has to pay apple to get a subscription, and to bet granted a title like this might need even more work.
Even if a qemu developer got the entitlement, it is still not fit to the qemu project very well, because all binaries has to be signed by the developer who has the entitlement, but qemu does not offer official binary releases, the binaries are complied by the ones who distribute it.

 

[jdb8167]

The developer has to pay apple to get a subscription, and to bet granted a title like this might need even more work.
Even if a qemu developer got the entitlement, it is still not fit to the qemu project very well, because all binaries has to be signed by the developer who has the entitlement, but qemu does not offer official binary releases, the binaries are complied by the ones who distribute it.

Good point. I wonder if individual developers can get the entitlement for development purposes without a lot of hassle. Then anyone who wants to build the binaries themselves could turn on bridge mode and anyone using QEmu in their product would need to get the production entitlement.

 

[Gnattu]

Good point. I wonder if individual developers can get the entitlement for development purposes without a lot of hassle. Then anyone who wants to build the binaries themselves could turn on bridge mode and anyone using QEmu in their product would need to get the production entitlement.

The best case for us is that brew or macports can get the entitlement and distribute the compiled binaries with bridged networking.

 

[Gnattu]

I wonder if individual developers can get the entitlement for development purposes without a lot of hassle.

If Apple is that kind we can try to present them the ACVM project, saying we are developing a virtualization software and want to add bridged network, and Apple may gave us the entitlement if we want to pay.

 

[jdb8167]

The best case for us is that brew or macports can get the entitlement and distribute the compiled binaries with bridged networking.

Macports still doesn't build QEmu as of this weekend. I'm not sure what the hold up is since I can build it from git with most of the requirements from Macports. Maybe they have a policy of not using unofficial patches? Which would be strange since Macports uses patches everywhere.

 

[haralds]

It's a framework, so it does not need a special certificate. Developer signing is ok.
Homebrew builds on the local machine, so it should be ok.

 

[Gnattu]

It's a framework, so it does not need a special certificate. Developer signing is ok.
Homebrew builds on the local machine, so it should be ok.

I tried that:
Unfortunately it is not OK.

I tried to sign that with my development certificate, and tried to sign it without certificate, and both get killed:


If I remove com.apple.vm.networking entitlement but keep com.apple.security.hypervisor and sign it, it works even without a certificate:

We DO need permission from Apple to use that framework, unfortunately.