Jump to content

VT-d problems in macOS


badbrain
 Share

58 posts in this topic

Recommended Posts

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 by badbrain
  • Like 4
  • Thanks 1
Link to comment
Share on other sites

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 by miliuco
  • Like 2
Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

@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):

table.png.629104402305bbfd8f7ab5346317dbf0.png

 

 

Edited by miliuco
Pict size changed.
  • Confused 1
Link to comment
Share on other sites

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

table.png.629104402305bbfd8f7ab5346317dbf0.png

 

 

Not a rule.

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by iGPU
  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

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 by buzzworm
Link to comment
Share on other sites

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 by buzzworm
Link to comment
Share on other sites

  • 1 year later...

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

Screenshot 2023-10-29 at 18.20.49.png

  • Like 5
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by deeveedee
Link to comment
Share on other sites

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.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

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 by deeveedee
Link to comment
Share on other sites

 Share

×
×
  • Create New...