VT-d problems in macOS

[badbrain]

The problem that many people have here is that you can't enable VT-d in UEFI and disable DisableIOMapper on every platform, just like that. For this reason there is this kernel-quirk.

This was intended for the fact that one can leave VT-d active in the BIOS, in order to be able to use it at least in another system, because AppleVTD does not run on each system problem-free without making changes at DMAR and dropping the original DMAR table.

Unfortunately this was not considered when introducing the ForceAquantiaEthernet quirk and that's why there are now the complaints that e.g. WIFI doesn't work anymore when following the instructions.

That the Fenvi T919 did not work in @Rankrotten 's case has nothing to do with the card itself, even a BCM94360NG would not work here.

 

This is due to the bad implementation of VT-d in the firmware of the (older) consumer boards. On server and HEDT platforms it usually works properly.
X299 and newer platforms, like Z690 and partly Z590, don't seem to be affected by this problem, but everything before that apparently is. 

 

With an AMD hack, you're probably at a complete loss there, as I think enabling AppleVTD will prove much more difficult, if not impossible (maybe a patch can help, but I don't know). 

AMD's equivalent to Intel's VT-d is AMD Vi / AMD I/O or IOMMU and not SVM - SVM is the equivalent of VT-x.

 

After enabling VT-d in the BIOS of an Intel system and with the DisableIOMapper quirk disabled, you will see AppleVTD quite high up in the IORegistryExplorer (IOService).

 

With AMD systems, it would be now interesting to know whether one can see AppleVTD after the activation of IOMMU in the BIOS likewise in the IORegistryExplorer, which will be however rather not the case,

because for AMD systems, IVRS indicates I/O MMU (IOMMU) support and not DMAR.
 

Edited April 23, 2022 by badbrain

[miliuco]

User kokowsky in this @PMheart's thread says how to modify DMAR table to be able to have Aquantia and wifi working with DisableIoMapper disabled in config.plist and VT-d enabled in BIOS plus ForceAquantiaEthernet selected.

Modified DMAR.aml table must be in ACPI folder and config.plist and system DMAR table must be dropped in ACPI >> Delete.

 

Note: DMAR code can be different in your mobo, last Reserved Memory region and PCI (path 14,00) must be removed.

Credits to @PMheart, kokowsky and others.

 

 

Edited April 26, 2022 by miliuco

[Guest 5T33Z0]

PCI paths may and number of Reserved Memory Regions may vary (my DMAR table has 2 Memory Regions for example). So unless you know which PCI path is used just delete all reserved memory regions, or drop the table completely. 

[miliuco]

@5T33Z0

Yes, I know paths and regions can vary in different mobos. I don't have Aquantia but, if I drop completely DMAR table (thanks to you I know how to do this), I loss my Ethernet and wifi. Changing DMAR table as per comments, both interfaces work fine. So it's possible that dropping DMAR doesn't work in all cases.

[Slice]

21 hours ago, miliuco said:

User kokowsky in this @PMheart's thread says how to modify DMAR table to be able to have Aquantia and wifi working with DisableIoMapper disabled in config.plist and VT-d enabled in BIOS plus ForceAquantiaEthernet selected.

Modified DMAR.aml table must be in ACPI folder and config.plist and system DMAR table must be dropped in ACPI >> Delete.

 

Note: DMAR code can be different in your mobo, last Reserved Memory region and PCI (path 14,00) must be removed.

Credits to @PMheart, kokowsky and others.

 

 

PCI path 14:00 corresponds to XHCI controller on chipsets up to 9-gen.

Can anybody show me list of PCI devices for Z590 and Z690 chipsets? Or just Clover's preboot.log.

[badbrain]

1 hour ago, Slice said:

PCI path 14:00 corresponds to XHCI controller on chipsets up to 9-gen.

So it is also on Rocket- and Alder Lake.

Edited April 26, 2022 by badbrain

[1Ale1]

6 hours ago, Slice said:

Can anybody show me list of PCI devices for Z590 and Z690 chipsets? Or just Clover's preboot.log.

PCIInfo.txt

 

This is from an ASUSTeK COMPUTER INC.TUF GAMING Z590-PLUS WIFI

 

Edited April 26, 2022 by 1Ale1

[Slice]

Thanks, the PCI 14,0 is always XHCI controller.

So it is strange to see that to make LAN working we have to exclude this area from DMAR. What is the relation?

[Slice]

On 4/26/2022 at 12:38 AM, 5T33Z0 said:

PCI paths may and number of Reserved Memory Regions may vary (my DMAR table has 2 Memory Regions for example). So unless you know which PCI path is used just delete all reserved memory regions, or drop the table completely. 

I think the region must be removed not for Aquantia but for the system will not crash because of XHCI.

Did you set XhciPortLimit? If yes, disable it!

[miliuco]

@Slice

As you say, it seems that it has to do with more things, not only with Aquantia.
I don't have Aquantia, I have Eth Intel I219V7 and wifi Fenvi T919 with Z390 chipset and I have seen this (all with VT-d enabled in BIOS):

 

 

Edited April 27, 2022 by miliuco
Pict size changed.

[Slice]

1 hour ago, miliuco said:

@Slice

As you say, it seems that it has to do with more things, not only with Aquantia.
I don't have Aquantia, I have Eth Intel I219V7 and wifi Fenvi T919 with Z390 chipset and I have seen this (all with VT-d enabled in BIOS):

 

 

Not a rule.

I have Z170 chipset, I219 eth, VT-d is enabled, DisableIoMapper disabled, DMAR as is. Eth is OK.

[miliuco]

@Slice

I see, this can vary from system to system.

 

Edited April 27, 2022 by miliuco

[Slice]

[i0ntempest]

I actually did DMAR patching well before the old Aquantia patch was broken by the OS update, in an attempt to fix my Thunderbolt stuff.

What's interesting is that, on my secondary hack that is using a QNAP AQC111U 5GbE adapter, with modified DMAR table, DisableIoMapper must be enabled for it to work. Otherwise I seem to get frequent link up/down, though the indicator light on the adapter shows everything is normal. Onboard Realtek ethernet seems unaffected.

[miliuco]

@Slice

Me too, if VT-d enabled and DisableIoMapper disabled >> AppleVTD exists in Ioreg.

 

@i0ntempest

Differences from system to system.

[iGPU]

On 4/26/2022 at 10:26 AM, Slice said:

PCI path 14:00 corresponds to XHCI controller on chipsets up to 9-gen.

Can anybody show me list of PCI devices for Z590 and Z690 chipsets? Or just Clover's preboot.log.

 

Here is a PCI list for an ASUS Z690 ROG Maximus Extreme. All USB ports on mobo (aside from those on TB) appear under XHCI.

 

AppleVTD is active with stock DMAR (there seem to be no Reserved Memory sections for this mobo to drop), with VT-d enabled and DisableIoMapper disabled.

 

[The PCI list shows 2 NVMe and 3 PCIe AIC: one 6900 GPU in slot 1, a Wifi/BT card in slot 2 and a Vega 56 in slot 3. When booted into Mojave, the 6900XT is cancelled and for BS and Monterey, the Vega 56 is cancelled. Thunderbolt is built-in. The ethernet controllers are I225V and AQN113C.]

 

 

 

pcidevices.txt

Edited May 2, 2022 by iGPU

[buzzworm]

Running 0.8.0 / 12.3.1

Here's something I found on my Z390 Gaming M

 

i219 Ethernet works (with VT-D off)
Aquantia 107 works (with VT-D on) and ForceAquantiaEthernet set to TRUE
If VT-D on, i219 and wifi do not work.
If VT-D on, Aquantia 107 receives a 169.x.x.x address.

If VT-D off / DisableIoMapper TRUE, then Aquantia 107 still receives 169.x.x.x

Edited May 17, 2022 by buzzworm

[Slice]

I don't think i219 depends on VT-d. It works for me no matter on VT-d settings.

[buzzworm]

in clover, VT-d on or off and i219 works fine.

What in my OC config would cause it to not work with it VT-d on?

 

---

woops... looks like my AQ107 isn't working right now on Clover either. lol. FML. Hackintoshing make me grey.

Edited May 17, 2022 by buzzworm

[Slice]

Successfully installed 14.2 after a week of faults.

The reason is VT-d which was ON up to Sonoma 14.0. But when I installed Sonoma 14.1 the VT-d leads to deep hang after a few seconds of kernel start.

Strange but my case of VT-d worked no problem from Mojave up to Sonoma 14.0 final and not working in Sonoma 14.1+.

[Slice]

I made cutted DMAR.aml table and load it by Clover. Yes, it works! I can enter Sonoma14.2 while with OEM DMAR I can't.

[Slice]

There is Reserved Memory Region

[050h 0080   2]                Subtable Type : 0001 [Reserved Memory Region]
[052h 0082   2]                       Length : 0020

[054h 0084   2]                     Reserved : 0000
[056h 0086   2]           PCI Segment Number : 0000
[058h 0088   8]                 Base Address : 000000005E706000
[060h 0096   8]          End Address (limit) : 000000005E725FFF

But how it is used?

I got memory map and see

"(EFI) EfiReservedMemoryType"   0x000000005E444000  0x000000005E78BFFF  

So this memory region is already inside Reserved Memory region. So why it is wrong for new Sonoma?

[deeveedee]

17 minutes ago, Slice said:

I made cutted DMAR.aml table and load it by Clover. Yes, it works! I can enter Sonoma14.2 while with OEM DMAR I can't.

It's been a while since I last looked at DMAR and VT-d.  Sorry for the remedial questions:

1. What tool are you using to edit DMAR table?
2. Are you simply deleting the Reserved region or are you replacing with NOOP instructions?  I'm asking, because PMHeart's instructions say "If you need to remove this part, then NOP instructions will work. It is 04 for ACPI. i.e. by replacing this part into all 04."

Edited November 1, 2023 by deeveedee

[Slice]

13 hours ago, deeveedee said:

It's been a while since I last looked at DMAR and VT-d.  Sorry for the remedial questions:

1. What tool are you using to edit DMAR table?
2. Are you simply deleting the Reserved region or are you replacing with NOOP instructions?  I'm asking, because PMHeart's instructions say "If you need to remove this part, then NOP instructions will work. It is 04 for ACPI. i.e. by replacing this part into all 04."

1. HexFiend - it is just hex editor where I see all bytes in the table. I know byte #5 is a table length so I change it from 0x70 to 0x50.

2. Delete all bytes from offset 0x50 up to the end of file.

As I see the result the method is working.

[deeveedee]

Is AppleVTD SMBIOS-specific?  The reason I ask is that I believe I modified my HackBookPro6,2 's DMAR table but I don't see AppleVTD in IORegistry Explorer.  Note that I didn't need to modify DMAR and don't expect any behavioral changes resulting from the modified DMAR - I was just curious.  Should I see AppleVTD on my HackBookPro6,2?  Details below...

 

I enabled VT-d in BIOS on my Dell Latitude E6410 (SMBIOS MBP6,2) and extracted table DMAR (using MacIASL).  I then edited the DMAR table to remove the Reserved Region at the end of the table (used MaciASL to edit the table and adjust the table length).  I added the modified DMAR table to EFI/OC/ACPI, added DMAR to ACPI > Add and ACPI > Delete in my config.plist and disabled Kernel > Quirks > DisableIoMapper in my config.plist.  After rebooting Sonoma 14.1 with the modified DMAR, I confirmed the modified DMAR table with MacIASL (File > New from ACPI > DMAR) and the table is properly modified/loaded.

 

After modifying DMAR, my HackBookPro6,2 does not have AppleVTD in IORegistry Explorer.  Should I see AppleVTD?

Edited November 2, 2023 by deeveedee