How Do I Disable Virtualization?

[TechProgenitor]

Earlier this year, I acquired a graphics amplifier and a 6950XT. After configuring everything and spoofing the setup, I’m encountering a kernel panic in macOS whenever the eGPU is connected during initialization. The panic seems to be triggered by a function related to virtualization, which leads me to believe that I need to disable VMM-related settings in my BIOS. However, these settings for me are hidden, and writing to the individual offsets with RU hasn’t helped disable the feature. (I can tell through the Windows Task Manager that Virtualization remains enabled.)

I noticed that @kingo132 has the BIOS option "VT for Direct I/O" disabled and am curious if the BIOS was modified to reveal that setting? I followed a tutorial to extract and edit my BIOS in order to show this option, but I’m running into Error 167 when attempting to flash the newly modified BIOS back.

[kingo132]

You can try ru.efi: https://ruexe.blogspot.com/. And find the offset by this file: https://github.com/kingo132/a51m-r2-5700m-hackintosh/blob/main/a51mr2_biosdump.txt, which would be: VT-d, VarStoreInfo (VarOffset/VarName): 0xF9, VarStore: 0x16

[TechProgenitor]

I changed the values at offsets 0xB4 and 0xF9 to 0, but virtualization still seems to stay enabled.

On my other laptop, virtualization is visible within the BIOS settings, and disabling it works as expected.

I'm interested to know if you use this amplifier with a GPU yourself? If so, is there any chance you've tried modding this BIOS using an EEPROM programmer? The BIOS is split across two ICs near the RAM, and I've managed to use a CH341A to merge the dumps from both chips into a complete BIOS. After unlocking the necessary settings and splitting the modified code back across the chips, the laptop fails to post. I believe this is due to a checksum error, as I receive a checksum error notification during startup after restoring the original BIOS.

Finally, I noticed your updated changelog. Not sure if this helps, but I have 2933MHz RAM installed on my laptop and experience similar page faults, but only when the iGPU is enabled. (I haven’t yet figured out how to make that card stable.) Assuming you get these crashes, even with a disabled iGPU, downgrading the memory is likely your best bet because I don't use an XMP profile myself.

[kingo132]

Hi, TechProgenitor, thanks for the tips!

Using RU.efi to modify the BIOS setting is the same as changing the options visibly in the BIOS, so as long as VT-d is disabled through RU.efi, it is disabled. However, I do also see that virtualization is still enabled in Task Manager. I did some research about this, and here is what ChatGPT explained of this:

Reprogramming the BIOS physically is too dangerous for me to do, so I give up.

I do have an Alienware Graphic Amplifier, but I'm using it with RTX4070ti on Windows (to play games). So, I haven't encountered that panic you have experienced.

[kingo132]

I still suspect this should be a problem from the graphic driver. Maybe you can try to update the WhateverGreen.kext to the newest version. The one in the repository is pretty old. Before updating to the newest version, try to merge my revised code to the newest version, otherwise, the brightness adjustment may not work. My WhateverGreen code is here: https://github.com/kingo132/WhateverGreen

If this still doesn't solve the problem, try to file an issue in the WhateverGreen repository.

Btw, setting the DisableIoMapper quirk to true in OpenCore is the same as disabling VT-d in BIOS. Try to enable this quirk to see if it makes any difference.

[TechProgenitor]

Hi kingo132, thanks for that info, it really clears things up. I didn’t know the difference between VT-x and VT-d, and my other laptop specifically calls the virtualization setting VT-x.

I’ve tried many things including DisableIOMapper, dropping the DMAR table, and the latest WhateverGreen without success. I’ll see what I can do about this issue, however, it baffles me because this guy gets the card working on the R1 with a Radeon VII. However, he has an internal NVIDIA card, and is using a different framebuffer.

[TechProgenitor]

By the way, I’ve been wanting to give you this for a while. It’s a version of AppleALC that eliminates the headphone distortion problem. ~The speaker output is still kinda finicky, but~ you’ll never have to enter that verb command again on startup/wake to fix the headphone output. All I had to do was add node 0x19 to the pin configuration.

AppleALC 1.9.2 A51M-R2 HPd Fix.zip

Edit: I managed to make the speakers behave by creating an Automator app that runs on startup.

[kingo132]

Hi TechProgenitor, thank you for providing your work. This AppleALC variant works quite well with no adapters in the headphone jack. Thanks, I appreciate this!

[TechProgenitor]

You're welcome! Ironically, hours after my last post, I made major progress with the audio output. I've attached below a new patch that enables auto-switching between the internal speakers and headphones. (I made a similar patch long ago, but the auto-switching behaved incorrectly.)

To make it work, I edited the path-map by isolating node 0x17 (Line Out) and combining nodes 0x14 (Internal Speakers) and 0x21 (Headphones). Somehow, this redirects audio from node 0x17 to node 0x14, solving the EAPD issue—hopefully, this still supports your forking adapter. However, when on battery, audio cuts out and switches back to node 0x17. Disabling SMCBatteryManager and ECEnabler makes the patch work perfectly.

I suspect the embedded controller (EC) is involved in routing audio between nodes 0x14 and 0x17. There’s likely a ≤ 8-bit field controlling this, but I’m struggling to get debug logs working.

I’ve debugged the EC before on my other laptop, but I can’t get ACPIDebug to work here. I dumped my DSDT using SysReport, added the RMDT method, instrumented EC queries, and enabled ACPIDebug and DebugEnhancer in the config.plist, but nothing shows up in the console when adjusting brightness/volume/etc.

Apologies for the shift in topic. I feel like we’re very close to solving the audio for good. If you manage to get the debug working, please share how you did it—I’d appreciate any insights!

Switching Works on AC Adapter.zip

[kingo132]

For the ACPI debugging, I've checked your EFI in that repo. One kext I had more than you is DebugEnhancer.kext. Also my boot-args is "keepsyms=1 debug=0x100 msgbuf=1048576 agdpmod=pikera swd_panic=1 -iosd3v3 applbkl=3 -dbgenhdbg -brcmfxwowl alcverbs=1 bpr_probedelay=100 bpr_initialdelay=300 bpr_postresetdelay=300", and yours doesn't have msgbuf=1048576, swd_panic=1, and -dbgenhdbg. Try adding these to see if there's any difference.

[TechProgenitor]

I’m receiving debug logs in the kernel during startup, but not in the console. Over the weekend, I took a closer look at the ACPI tables and realized I might have been wrong in assuming the embedded controller was related to the audio issue.

The issue can be narrowed down to the _PSR, _BST, _BIF, and _BIX methods. Removing the _PSR and _BST methods simulates the system running on low battery in macOS, which triggers the audio problem. The _BIF and _BIX methods simply return an array of information about the battery, which seems unrelated to the audio issue. (The methods also get called on AC power without issues.) However, if you delete all four methods entirely (as if no battery is present), the audio works perfectly.

This leads me to believe macOS might be handling the audio patch differently depending on whether it believes a battery is present or detects AC, likely to conserve power.

Thanks for taking the time to review my EFI! I was really excited when I first got this new audio patch working, but I’m unsure what macOS is doing on battery. Worst case, we can always fall back on the HPd-Fix patch and Automator app, which seems to handle things just fine. Regarding the Amplifier thing, I'll try to see if someone's gotten two or more Navi GPUs working in macOS over PCIe.