Parallels Desktop for Mac computers with Apple silicon M4 chips

Linux kernel fix here: https://lore.kernel.org/linux-arm-kernel/20241203151941.353796-1-catalin.marinas@arm.com/. 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.

 

thanks

 

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

 

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_

 

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.

 

I have an M4 Pro MacBook Pro and I am unable to install certain Linux distributions as well. Windows and Fedora have been working for me but I'm failing to install Debian, Kali or Ubuntu. On my M3 machine they're working fine. I initially thought it could be a defective RAM on my Mac, but given the fact that everything on the macOS side as well as Windows/Fedora VMs have been working fine, I've come off that suspicion.

I'm using App Store version 1.10.1 (newest version) which should be compatible according to Parallels.

Here are some screenshots with the error message I'm getting. As other users have already pointed out, it's often failing at the "ca-certificates" or "initramfs" step with issues such as "segfault" or "sigsecv".

This issue is definitely not resolved and I hope you folks at Parallels are treating it seriously and with highest priority (I've also opened an official support request through my account).

 

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).

 

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.

 

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.

 

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.

 

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 20241203151941.353796-1-catalin.marinas@arm.com
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

 

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.

 

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

 

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.

 

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.

 

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!

 

still no updates from Parallels???

 

• 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.

 

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.