Parallels Desktop for Mac computers with Apple silicon M4 chips

[cmarinas]

Linux kernel fix here: https://lore.kernel.org/linux-arm-kernel/[email protected]/. It will take some weeks before it ends up in distro kernels, even longer for the distro installers to be updated. So an updated Parallels that does not hide the 16-bit ASID feature would avoid hitting this Linux bug.

 

[krkbelgelendirme]

thanks

 

[Freddy2]

Linux kernel fix here: https://lore.kernel.org/linux-arm-kernel/[email protected]/. It will take some weeks before it ends up in distro kernels, even longer for the distro installers to be updated. So an updated Parallels that does not hide the 16-bit ASID feature would avoid hitting this Linux bug.

Hi Catalin,
I'm getting the following issue after The parallels Tools was installed and the VM (Kali Linux 2024.2) tried to restarts (see img).
Do you think that this related with the same bug that you have mentioned previously ?

Thanks !!
Fred

 

[FlipR]

Can someone run Passmark Performance test 11 on his M4 Pro or Max under Windows 11 Pro and Parallels 20 Pro?
This is what I get on my Mac Studio 1 Max.
I would appreciate it very much if you post your result.
You can download the app here https://www.passmark.com/products/p...IWWh0WjzN-Axz2kIz8aQ75kiOqXajJFxtcy9TzQEr1z8_

 

[cmarinas]

Hi Catalin,
I'm getting the following issue after The parallels Tools was installed and the VM (Kali Linux 2024.2) tried to restarts (see img).
Do you think that this related with the same bug that you have mentioned previously ?

Thanks !!
Fred

It does not seem related. The error reported is that it could not mount the root filesystem. With the bug being described earlier it's only once user-space apps started. In your screenshot, the kernel did not get to that point yet.

I can't tell what happened with your configuration. Check that the disk images are still attached to the VM.

 

[Parallels User]

>>> Message has been deleted by the user <<<

 

[Parallels User]

>>> Message has been deleted by the user <<<

 

[cmarinas]

Same issue here. I managed to install Fedora NetInstall, but am suffering from the exact same issue in Ubuntu, Kali, Debian (M4 Pro MacBook Pro, Parallels App Store 1.10.1.

Please read the thread, at least the latest messages (around page 6). In short, it's a Linux bug from day 0 that went unnoticed until M4 enabled 16-bit ASIDs but Parallels still reports 8-bit ASIDs to the VM. The Linux kernel has been patched but it will take time for the fix to turn up in distro installers.

Temporary workaround - only enable a single CPU in the Parallels VM configuration. I'm really hoping Parallels will update their software to report 16-bit ASIDs to Linux, as per the hardware support, but I haven't seen anything yet (this would allow an unpatched Linux to run fine).

 

[8bitcoffee]

Hi there!
Parallels deeply cares about the quality of our products and the experience they provide.
This thread has been created to share feedback on the work in Parallels Desktop on Mac computers with Apple M4 chips. Don't hesitate to share your experience!

Hi Mikhail,

It's been asked a number of times by others, will Parallels provide support and provide timely fix for v19 users running on M4 macs (in my case for Windows 11 VMs)? Can we please get an official response given you indicate that Parallels "deeply cares about the quality...and the experience they provide". I've asked in my own case #5071242.

As noted by others, your supportability matrix has a checkmark (and * indicating that for Sequoia it might not be fully optimized and compatible). It also links to issues list that doesn't even mention this, and M4 compatibility has been voiced in this forum almost a month ago. To be clear, this is a showstopper and there shouldn't even be a checkmark for Sequoia on M4 Macs, it won't even start.

We'd all like clarity, is Parallels working on this and going to address for v19 users, or is update to v20 the only solution. Thanks.

 

[KeithC5]

Linux kernel fix here: https://lore.kernel.org/linux-arm-kernel/[email protected]/. It will take some weeks before it ends up in distro kernels, even longer for the distro installers to be updated. So an updated Parallels that does not hide the 16-bit ASID feature would avoid hitting this Linux bug.

I tried it in my Ubuntu instance in Parallels by compiling a new kernel by hand using the changes listed above in the kernel patch. So far so good. No segfaults from mkinitramfs yet for about 20 minutes so far. The fix was a little work and confusing if you don't know what you're doing. It also complicates apt installs/upgrades for me; the custom kernel I compiled conflicts with the Ubuntu version of the kernel when I try to update or install packages from apt. I'm still playing around with it to get it right, but at least it's not crashing, and I can run multicore CPU in arm64 Ubuntu under Parallels. I hope Ubuntu gets this patch out soon so we can all get a future apt update.

 

[GeorgeH19]

I also have this issue - at least when the vm is running on multiple processors with Debian on a m4 Mac.

mostly it gets tickled by make -j N workloads. But I get stack smash reported in lots of places randomly.
I am tempted to build a kernel for that vm image with the above patch. But I'm curious if that's the right route to go.
If there's a fix that parallels could apply that would be fantastic.

 

[GeorgeH19]

I can confirm that the above seems to fix things running on debian over an m4 mac.

Steps to fix:

Start VM with one processor allocated only to avoid smash issues whilst creating fix.


With one processor allocated

```
sudo apt-get install linux-source-6.1
tar xaf /usr/src/linux-source-6.1.tar.xz
cd linux-source-6.1

make defconfig
scripts/config --disable DEBUG_INFO
scripts/config --disable DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT

sudo apt install python3.11-venv
python3 -m venv .venv
source .venv/bin/activate
pip install b4

b4 -o patches [email protected]
patch -p1 <patches/20241203_catalin_marinas_arm64_ensure_bits_asid_15_8_are_masked_out_when_the_kernel_uses_8_bit_asids.mbx

make bindeb-pkg

sudo dpkg -i ../linux-image-6.1.119_6.1.119-3_arm64.deb
sudo dpkg -i linux-headers-6.1.119_6.1.119-3_arm64.deb
```

The headers are needed for parallels toolbox which will try to autoupdate

Let parallels toolbox install and reboot

 

[RAM4]

Linux kernel fix is available. It will take a few weeks before this fix is included in distro kernels, and even longer for distro installers to be updated. Therefore, using an updated version of Parallels that doesn't hide the 16-bit ASID feature would help avoid this Linux bug.

 

[RAM4]

This is an excellent explanation! You've provided a clear timeline of how the fix will be rolled out, and the recommendation to use an updated version of Parallels is very practical. It's great to see such a well-thought-out solution for avoiding the Linux bug. Your insights are incredibly helpful for anyone navigating this issue. Thanks for sharing

 

[SherwoodW1]

Please read the thread, at least the latest messages (around page 6). In short, it's a Linux bug from day 0 that went unnoticed until M4 enabled 16-bit ASIDs but Parallels still reports 8-bit ASIDs to the VM. The Linux kernel has been patched but it will take time for the fix to turn up in distro installers.

Temporary workaround - only enable a single CPU in the Parallels VM configuration. I'm really hoping Parallels will update their software to report 16-bit ASIDs to Linux, as per the hardware support, but I haven't seen anything yet (this would allow an unpatched Linux to run fine).

The standard Debian image works with a single CPU. I used it to build Linux 6.1.120. Linux 6.1.120 works well with more CPUs. The upstream incremental patch from 6.1.119 to 6.1.120 has no conflict with Debian kernel team's patch set for 6.1.119-1.

 

[cmarinas]

I also have this issue - at least when the vm is running on multiple processors with Debian on a m4 Mac.

mostly it gets tickled by make -j N workloads. But I get stack smash reported in lots of places randomly.
I am tempted to build a kernel for that vm image with the above patch. But I'm curious if that's the right route to go.
If there's a fix that parallels could apply that would be fantastic.

The Parallels fix is simple - just report 16-bit ASIDs to Linux as per the hardware support. Qemu/UTM does this already. Not sure why it takes Parallels engineers so long to update, it's just a constant. Parallels already jumps through the hoops of trapping the ID_AA64* register accesses just to mislead the VM on the number of ASIDs. I have a suspicion they want to make sure it doesn't break Windows but this should work fine with 16-bit ASIDs since most Arm CPUs these days have moved on from 8-bit ASIDs.

 

[MattiasB]

Linux kernel fix here: https://lore.kernel.org/linux-arm-kernel/[email protected]/. It will take some weeks before it ends up in distro kernels, even longer for the distro installers to be updated. So an updated Parallels that does not hide the 16-bit ASID feature would avoid hitting this Linux bug.

For the ones that dont want to wait for the trickle down, I built a kernel from ubuntu src deb pkg and installed it following the ubuntu intructions. Now all is fine with multiple vCPUs. Thanks Catalina!

 

[AlexeyS8]

still no updates from Parallels???

 

[ApekshaM]

Linux kernel fix here: https://lore.kernel.org/linux-arm-kernel/[email protected]/. It will take some weeks before it ends up in distro kernels, even longer for the distro installers to be updated. So an updated Parallels that does not hide the 16-bit ASID feature would avoid hitting this Linux bug.

• If the issue persists, consider installing a third-party utility like MacMouseFix or SmoothScroll in Windows to improve Magic Mouse functionality.

• Ensure both Parallels Desktop and macOS are updated to the latest versions, as updates often include bug fixes for hardware compatibility.

• If none of the above steps work, this could be a compatibility issue with the M4 chip or the specific Windows version. Contact Parallels Support for a more detailed resolution.

 

[Mikhail Ushakov]

Hello!
The issue related to the inability to install/run Linux virtual machines on Apple silicon Macs with M4 chips has been addressed in Parallels Desktop 20.1.3. Please install this version to resolve the issue.