Drop DMAR Table vs DisableIOMapper

[J Lamp]

I could use a little clarification on this on.

 

My config.plist files have always had DMAR listed in the Drop Tables section. As I've now updated Clover from 5122 to 5149 (so I can move on from Mojave) it seems that the DMAR table is no longer being dropped.

 

I had simply (and incorrectly it seems) assumed that I could use my old config.plist, modify it in the latest Clover Configurator and that would add the required quirks to work with the new OpenCore memory management. Using BBEdit and looking at the the sample config.plist that came with version 5149, I can see that there are a whole bunch of default OpenCore quirks set in that plist that don't show up in Clover Configurator. One of those is DisableIOMapper, which is set to true. If I understand it right, that removes the DMAR table.

 

Slice had suggested that I modify my DMAR table (apparently I should remove the "Reserved Memory" section) and create a custom SSDT so that I can allow VT-D to enable my 10G network in Monterey and not have to use dart=0 when booting Mojave. It seems though, that when I use MacIASL > New From ACPI, I still have the original DMAR table, when I add my modified one MacIASL shows 2 DMAR tables and when I try to use "AutoMerge" in Clover Configurator I get a panic no matter what OS I try to boot. Using the Drop Tales section to drop DMAR doesn't seem to be working.

 

Just so I'm clear moving forward, what's the status on the "Drop Tables" section in the config.plist? Should I be using "DisableIOMapper" to drop DMAR and if so, is it just DMAR that is affected or are there other tables as well that should be dealt with using the new OpenCore methods?

 

Edit - Just a quick update, enabling "DisableIOMapper" breaks my AQN-107 ethernet card, even with a customized DMAR table installed. The DAMR table still shows up as well. Maybe I'm just doing something wrong.

Edited October 7, 2022 by J Lamp

[etorix]

The overall purpose is to have Intel VT-d working.

To achieve this:

• VT-d must be enabled in BIOS;
• DisableIOMapper quirk must be disabled;
• there must be a DMAC (Direct Memory Access Controller) device (look for 'PNP0200' in DSDT, if there is one device with this _HID property, it's fine; if here is none, add SST-DMAC).

And, for the proper working of all devices, macOS must be able to access all memory regions it wants to access. This is where the DMAR table (DMA Remapping) comes into play. Inspect the native DMAR table and look for any reserved regions. If there are no reservations, you're all fine.

If there are reservations in DMAR, make a copy of the table and delete the reserved regions: This becomes your custom SSDT-DMAR. Then drop the native DMAR table ("Drop Tables" in Clover; ACPI>Delete in OpenCore, TableSignature: DMAR) and add your custom SSDT-DMAR instead. (This is the same as dropping the native DSDT and replacing it by a modified version: To replace completely, the original table must be dropped; and if a table if dropped, there must be a replacement.)

 

You may post your native DMAR (or your whole set of ACPI tables) here.

Edited October 8, 2022 by etorix
typo

[J Lamp]

Hi etorix:

 

Thanks very much for the reply.

 

Yes I understand that I need to have VT-D working for the latest few versions of MacOS and I do have it working, otherwise my Aquantia network card doesn't fire up.

 

I also understand that I should use a patched DMAR (remove the Reserved Memory sections) and with that I should be able to boot up prior OS's (such as Mojave) without any trouble using the patched DMAR and without dart=0.

 

My question however was specifically about using "Drop Tables" and DMAR. Using Clover 5149 it's not dropping the original DMAR table. If I try to use the patched one I end up seeing 2 DMAR tables when I use MaciASL > New from ACPI

 

I just tried booting with Clover 5122 and an older Mojave install, dropping the DMAR table is working correctly there.

 

I had thought that since aspects of OpenCore are now part of Clover perhaps I was supposed to use a different method to drop the DMAR table. From what I've read it looks like the OC quirk DisableIOMapper is somewhat equivalent to using dart=0, but neither of those allow the original or the alternate patched DMAR to function.

 

As I've read a bunch of posts regarding this, it certainly sounds like most people are having success. I did find a guy on Reddit having exactly the same problem as me. Reddit - Dropping DMAR in Clover 5146 I tried the suggested method there of enabling AutoMerge to replace the original DMAR with the patched one, but when I did that I got a panic during boot no matter what version of MacOS I try to load.

 

It would seem like a software regression in Clover, but others, such as yourself, seem to have it working, so I thought that maybe there was a new way of going about dropping the DMAR table that I was missing.

 

I don't have another machine handy here to test this on, but on my x299 rig Clover 5149 is definitely not dropping the original DMAR table.

[etorix]

I do not use Clover, and I'm not very familiar with it. But I think that dropping ACPI tables should be independent from the OpenCore-inherited quirks.

 

DisableIoMapper disables VT-d, so this must be off. There should be no 'dart=0' argument and VT-d must be enabled in BIOS.

Can you boot with these settings? Not trying to drop DMAR or adding your own SSDT-DMAR at this stage.

[J Lamp]

Understood about DisableIOMapper and dart=0, I was looking at these because dropping the DMAR table wasn't working and I thought I was simply missing something new.

 

I can boot Monterey without any trouble. The DMAR table gets passed to the OS regardless of the "Drop Tables" setting in Clover. It seems that I don't need to remove the Reserved Memory section for Monterey, it works fine.

 

I cannot boot Mojave though with Clover 5149 unless I use dart=0. The original DMAR table is passed to the OS and it panics early in the boot process. I need to use dart=0.

 

I just tried this with Clover 5122 (which I know does drop the DMAR table correctly) loading Mojave and using the patched SSDT-DMAR.aml, it panicked during boot anyway.

 

So for now I think he simplest thing for me to do is stick with a custom entry for my Mojave drive that injects dart=0 for that OS. Everything in Mojave works fine without VT-D, including all the network cards.

 

I very much appreciate your help on this etorix, you've helped me get a much better sense of what's going on and where the problem is. Cheers!

[Alexey Boronenkov]

This is how you can delete a DMAR table in OpenCore and add your modified one

[Slice]

With recent Clover DMAR table is dropped successfully.