Enthusiast
Enthusiast

VMX option to disable use of XSAVE instruction under Big Sur

I am running Big Sur on "unsupported" hardware - a Mac Pro 5,1. With updated graphics and WiFi/BLE it is actually running without patches,

To avoid KEXTs VMware 12 is using some extended instructions  like XSAVE under Big Sur. Parallels still allows using it with KEXTs and works fine right now.

Is there a VMX parameter to disable this?

monitor.allowLegacyCPU = "true" does not do it.

Tags (2)
20 Replies
Community Manager
Community Manager

Unlikely... on Big Sur it's an entirely new monitor stack.

We would have to load the entire vmx86 kext, and that can't happen on Big Sur.

I'm curious tho, what is the use case behind the request?

- Michael Roy - Product Line Manager: Fusion & Workstation
0 Kudos
Contributor
Contributor

The use case?

That's easy, you can not use VMWare Fusion 12 at cMP 5.1 any longer. I have the same problem, it's not possible to open a VM because there is an error message of missing XSAVE support.

Screenshot 2020-09-19 at 11.10.23.png

sysctl -a | grep machdep.cpu.features

machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 POPCNT AES PCID

Independently of the guest OS, nothing works. As guest OS it's no problem to start Big Sur with Fusion 12 on Catalina (same machine cMP 4.1 > 5.1, 2x X5680 @3.33GHz).

I'm wondering why Parallels has no problems with this, Big Sur as host starts all old Parallel VMs and also Big Sur as guest OS with the latest version 16. So technically it's possible.

0 Kudos
Enthusiast
Enthusiast

Parallels loads the KEXT and it works.

Guess I am switching. I have used VMware products since Workstation 1 beta!

0 Kudos
Community Manager
Community Manager

Looks like you're using Big Sur... That Mac Pro isn't supported on macOS 11.x.

On Big Sur, we've completely done away with Kernel Extensions, quite deliberately.

As such, the remaining limitations are due to Apple's hypervisor API implementation. It requires certain hardware features.

I'm surprised it even boots on that Mac, tbh.

- Michael Roy - Product Line Manager: Fusion & Workstation
0 Kudos
Contributor
Contributor

I know that the hardware is not supported but this has been the case since Catalina, regardless Fusion worked perfect for me. The point is that Parallels 16 works anyway on Mac Pro 5.1. For me as normal user it's totally irrelevant how they technically implemented it, it works.

I will not buy a new machine only because Fusion is not working any longer on this machine, but Big Sur does. I guess it's time to say good bye after years. What a bummer, Fusion was always the better solution for me because of the interchange with VM Workstation on Windows.

There are a lot of Mac's which are unsupported but still will run Big Sur -> https://forums.macrumors.com/threads/macos-11-big-sur-on-unsupported-macs-thread.2242172/ .

At least an option to handle this would be nice, like haralds​ asked for.

Contributor
Contributor

I would like to add that running VMWare 12 on Big Sur on a MacPro5,1 is a desired use case for me as well.

Enthusiast
Enthusiast

Apple has deprecated Extensions (KEXTs,) but you can still load them.

It would be great if VMware would allow more experienced users to enable the older HyperVisor it uses on Catalina as Parallels does.

It is a bit of a hassle with "Allow"ing this in preferences and rebooting, but it beats ditching the VMware altogether.

Meanwhile I have switched to Parallels and am slowly converting all my VMs.

Contributor
Contributor

Hello @Mikero,

you say it is the API from Apple!

If I look at the configuration of a VM in Parallels, you can switch the hypervisor between "Apple" and "Parallels" (see attached screenshot, in German). Default is "Apple", and it works on my Mac Pro 5.1 with 2x X5690 processors.

So it seems to me this is not just a problem of Apples API !?

0 Kudos
Contributor
Contributor

Hello @Mikero,

if I start Parallels 16 and with setting "Apple" as hypervisor, there are no loaded kext's from Parallels in the system information apps (see attached screenshot).

So it looks to me that with the new Apple API it would be still possible to support a cMP5.1 or other older machines.

Can this be true?

0 Kudos
Enthusiast
Enthusiast

Hello Mikero,

 

We understand your confusion.  There are a LOT of people out there still running the 2009-2012 Mac Pro's with "unsupported" OS's.  There are various patch tools, including OpenCore, which make installing and using Catalina and Big Sur quite easy.  They also enable a lot of the features we've been missing on these older machines.  I'm using OpenCore with Catalina on my 2010 Mac Pro, and I can't think of a single macOS feature that doesn't work, including unlocking my Mac with my "Series Zero" Apple Watch.

Most of us perform extensive hardware upgrades, including dual 3.46GHz X5690 Xeon's, upgraded BlueTooth & WiFi, NVMe booting, USB3, AMD GPU's, such as the RX580, to achieve full AVC/HEVC encode/decode acceleration, and even Thunderbolt!

My point is that you're going to lose that share of the market to your competitor due to you only supporting Apple's hypervisor, whereas your competitor gives us the option of using theirs or Apples.  I hate to think this is the end of VMware for me, but it is what it is I suppose.  Can you confirm the business decision of only using Apple's hypervisor is final?

Thanks.

0 Kudos
Contributor
Contributor

I'm in the same boat. I upgraded my cMP 5,1 to Big Sur last night. When I tried to fire up VMWare Fusion this afternoon, I received the "The processor does not support XSAVE." I much prefer VMWare over Parallels, but I need to be able to run Windows. Parallels may be getting my money if VMWare can't provide a way forward with this issue.

0 Kudos
Champion
Champion

This may be a limitation of the Apple Hypervisor, if so, it's on apple to change for Fusion - and that also means that even Parallels will be done with Big Sur, since the next OS release will prevent kext's from loading at all.

0 Kudos
Enthusiast
Enthusiast

Apple is depreciating kernel extensions, and replacing them with system extensions. Parallels hypervisor is using system extensions. Why can't VMware do the same with Fusion?

0 Kudos
Contributor
Contributor

Hello @dlhotka ,

as I already showed in my screenshot attached above, I have Parallels 16 test version installed and it did not install any kext's, and in the configuration of the VM the hypervisor is "Apple" .I tested a Windows 10 and Ubuntu 20.04 VM and both worked, so for me it seems to be possible to run VM's on a cMP5.1 / Big Sur with the Apple hypervisor ...

0 Kudos
Enthusiast
Enthusiast

Very interesting... So VMware's implementation of the Apple hypervisor does not work due to our CPU's not supporting XSAVE, but Parallel's implementation of the Apple hypervisor is not using XSAVE? How is that possible, VMware?  Seems you're doing something different, and it's not Apple's fault after all...

0 Kudos
Champion
Champion

Evidently Parallels still has a kext option, and I would guess that's what you are seeing work.

0 Kudos
Enthusiast
Enthusiast

Parallels is not loading any KEXT's.  Perhaps it would help if you read up on the difference between a kernel extension and a system extension, and then what Parallels is doing might make more sense.  https://developer.apple.com/support/kernel-extensions

Also, here's an explanation from the vendor. https://www.parallels.com/blogs/system-extensions-big-sur/

The bottom line: Parallels is not loading any KEXT's. Parallels hypervisor works in Big Sur. Parallels implementation of APPLE's hypervisor does not throw the error "This processor does not support XSAVE", whereas VMware's implementation of APPLE's hypervisor does. That is the difference we're trying to get to the bottom of in the various Mac Pro forums and groups, before all of us leave VMware and move to Parallels.

Enthusiast
Enthusiast

My final reply... I gave my money to Parallels, rather than VMware Fusion v12, since BOTH Parallels and Apple's hypervisors work in Big Sur, without VMware's XSAVE requirement.  I'm now running Big Sur, but Parallels isn't without issues. Their networking is completely broken, so I'm having to route VM traffic through WiFi, but at least I'm able to run my VM's in Big Sur, and access my NAS. It's been a good, long ride VMware, but I'm afraid the ride is over.

Contributor
Contributor

@Mikero,

I personally expected more here.  VMware's own documentation says this is supposed to work...

https://kb.vmware.com/s/article/2005196

 

VMware Fusion Version Hardware Requirement Software Requirement

Fusion 12.X
  • All Macs launched in 2012 or later are supported except for the following:
    2012 Mac Pro Quad Core using the Intel® Xeon® W3565 Processor.
  • The following are also supported with a recommended graphic card that supports Metal:
    2010 Mac Pro Six Core, Eight Core, and Twelve Core.
Note: Mac running on non-x86 processors are not supported.
  • Fusion 12 is required on macOS 11 Big Sur and can also run on macOS 10.15 Catalina.
Note: Microsoft Windows is not included with VMware Fusion. Windows operating systems are available for purchase separately from Microsoft and other retailers.

 

So form what I can tell, someone at VMware should be looking into;

A) is the Mac Pro 5,1 with a metal capable GPU supported by Fusion 12.x or not?

B) Why is XSAVE a blocking error to begin with?  XSAVE is not a required feature for hypervisors to function. 

C) Why is VMware not leading the pack on this issue?  Every other hypervisor I have tested running BigSur on works...  Why is fusion the only one that fails?  If this isn't a BUG with fusion, then it is a bug with apples API and again VMware should be leading that discussion with Apple.

What shouldn't be done is exactly what has been done here...  Anyone running BigSur on a Mac Pro 5,1 already knows that it isn't officially supported by Apple.  Yes it older hardware.  But it does work and work quite well, and there is no technical reason that it shouldn't.  

 

TLDR;

It's either a bug with Fusion or Apples API, or VMware has failed to publish correct official documentation on what the requirements actually are for Fusion 12.  In any of these cases VMware needs to be actively driving the resolution here!  And for crying out loud this has sat long enough without a resolution.

So update the requirements, and get those refund checks ready... or fix it...

0 Kudos