Bad performance on VMware or hypervisor programs since Yosemite

I'm having the worst performance I've ever had with a program on my iMac since I bought it.

Program: VMware Fusion 7.0.1

OS: OS X Yosemite (10.10.1)

Mac model: iMac12,2 (27" mid 2011, i7, 16 GB RAM, HD6970M 2 GB)

I've seen that I'm not the only one on VMware forums and for what I have read, it's Yosemite's problem and it happens with every hypervisor program, so I've decided to put all the info here.

The way people are fixing this problem is by executing this command and rebooting after that.

sudo nvram boot-args="debug=0x10"

This is what VMware says:

Here is the result of our early investigation:

1) The root cause of the issue is a storm of interrupt 0x49 (apparently ACPI events, we are not sure yet) on CPU 0.

You can verify this by running the following command in Terminal:

sudo powermetrics -s interrupts

On the machine which I'm currently observing (remotely, using Screen Sharing), the command yields:

CPU 0:

Vector 0x49(iMac12,2): 105725.77 interrupts/sec

This rate of interrupts (more than one interrupt per microsecond!) is way too high.

2) The issue occurs regardless of whether Fusion (or a VM) runs or not. There is something seriously wrong on the machine. Fusion is just the messenger of the bad news.

3) The issue is a software regression in OS X. It does not happen when the host OS is Mavericks, it does happen when the host OS is Yosemite.

4) The issue only happens on specific hardware. So far we have identified iMac12,1 and iMac12,2 models. There might be others. But what is certain is that not all Macs are affected, or we would have found the issue much sooner.

5) Adding debug=<any non-zero value> to boot-args (using the nvram command) and restarting the host OS appears to suppress the issue. We do not know why at this point. The source code for the Yosemite kernel has not been released yet and the AppleACPIPlatformExpert class comes in the form of a binary-only kernel extension, which complicates further investigation. Nevertheless, the DB_KDB bit (value 0x10) has been a silent no-op in Mountain Lion and Mavericks, and it is likely a silent no-op in Yosemite as well. So for now, to workaround the issue, we recommend you add debug=0x10 to boot-args (using the nvram command) and restart the host OS.

6) Some forum users have reported that manually putting the Mac to sleep appears to suppress the issue as well.

7) VMware is about to file a Radar bug with Apple about this issue.