mmio whitelist Let talk about...Devirtualise MMIO quirk and MMIO Whitelist!

[fabiosun]

In this thread we will try to explain the function of this very interesting quirk and above all of the related section of MMIO Whitelist which is even more fundamental for different systems.

The topic has been recently documented in a more exhaustive way in the OpenCore configuration pdf, but nowadays it has assumed more and more value to have a Hackintosh at its maximum potential also in light of the new CPU architectures in use.

 

By default  the quirk is not active and for many systems it is not essential to make your hack work and start.

 

In December 2019 with the release of the third generation AMD ThreadRipper CPUs (sTRX4), many users, despite themselves, were forced to take an interest in the functioning of the quirk in question.

 

At that time the OpenCore documentation on the subject was not very exhaustive also because it was a quirk useful only for old systems.

 

With the sometimes cryptic help of the OpenCore developers (to whom thanks are always due for their work) they started to take the first steps to understand how to use it to debug on a platform like the one described above ( sTRX4) in conjunction with the MMIO Whitelist functionality.

link

 

By activating the quirk and only using a debug version of OpenCore with the Misc / Debug / Target option set to 67, it is possible, even with a machine that does not start, a debug in which the MMIO areas of your PC are highlighted (number of areas and values may vary):

08:808 00:001 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 0
08:809 00:001 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 0
08:810 00:001 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 0
08:811 00:001 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 0
08:812 00:001 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 0
08:813 00:001 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 0
08:814 00:001 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 0
08:816 00:001 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 0
08:817 00:001 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 0
08:818 00:001 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 0
08:819 00:001 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 0
08:820 00:001 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 0
08:821 00:001 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 0
08:822 00:001 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 0
08:823 00:001 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 0
08:825 00:001 OCABC: MMIO devirt 0x4040000000 (0x10400 pages, 0x8000000000000001) skip 0
08:826 00:001 OCABC: MMIO devirt 0x8BB0000000 (0x10400 pages, 0x8000000000000001) skip 0
08:827 00:001 OCABC: MMIO devirt 0x8BE0000000 (0x10400 pages, 0x8000000000000001) skip 0
08:828 00:001 OCABC: MMIO devirt 0xD750000000 (0x10400 pages, 0x8000000000000001) skip 0

 

It is of particular importance that these areas can be different even under conditions of the same BIOS and manufacturer, but only by swapping options in the BIOS or filling the nvme and pciexpress slots differently.

Note:

a common mistake is to take this list from any configuration and put it in your config.plist

It must always be taken and calculated in the system in use and rechecked if you change options in the BIOS or add hardware!

 

Activating the quirk involves having devirtualized memory areas and in some cases freed several megabytes of memory (typically from 64 to 256 Mb) which allows some problematic systems to start without having the notorious error at boot (memory allocation errors), and this right in the initial stages of the boot.

 

skip 0 means devirtualized area and if during its internal operations UEFI bios needed that area, not having it at its disposal, malfunctions or Kernel Panic would be created.

 

On the indications of the Opencore devs we concentrated on the last 4 areas which are the most substantial at the level of pages to possibly devirtualize and with 16 combinations (4!) It was established that the Kernel patches in use at the time were malfunctioning for sTRX4 systems. Let's now neglect this statement which turned out to be not exactly correct, but then it was practically a fact that led many sTRX4 users with the desire to use OSX on their machines to explore the fascinating world of ProXmox virtualisation.

 

Now the tests made at the time were to report the last 4 areas to full use of OSX (skip 1) in various combinations (16).

How?

By adding these areas in the Booter / MmioWhitelist section of our config.plist. To do this we are helped by the scientific calculator or the excellent app in the download area HackCheck (visible in the photo) for download it click below:

https://www.macos86.it/files/file/95-hack-check/

 

now let's just focus on the area:

08:828 00:001 OCABC: MMIO devirt 0xD750000000 (0x10400 pages, 0x8000000000000001) skip 0

 

and take the hexadecimal value 0xD750000000, this will be converted into a number as shown in the figure below:

 

 

and must be reported precisely in the appropriate area of the config.plist by activating it:

 

 

After saving the config.plist and restarting we will have this situation in our next debug log:

 

08:808 00:001 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 0
08:809 00:001 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 0
08:810 00:001 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 0
08:811 00:001 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 0
08:812 00:001 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 0
08:813 00:001 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 0
08:814 00:001 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 0
08:816 00:001 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 0
08:817 00:001 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 0
08:818 00:001 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 0
08:819 00:001 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 0
08:820 00:001 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 0
08:821 00:001 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 0
08:822 00:001 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 0
08:823 00:001 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 0
08:825 00:001 OCABC: MMIO devirt 0x4040000000 (0x10400 pages, 0x8000000000000001) skip 0
08:826 00:001 OCABC: MMIO devirt 0x8BB0000000 (0x10400 pages, 0x8000000000000001) skip 0
08:827 00:001 OCABC: MMIO devirt 0x8BE0000000 (0x10400 pages, 0x8000000000000001) skip 0
08:828 00:001 OCABC: MMIO devirt 0xD750000000 (0x10400 pages, 0x8000000000000001) skip 1

 

So the area we converted and inserted into the config by activating YES is now listed in the config as skip 1.

What does it mean?

It means that now this area is again available to UEFI Bios as if we hadn't activated the quirk..but only this MMIO area.

If in the lucky hypothesis that our system starts anyway and arrives at login, it is possible to proceed to insert and activate all the other areas in MMIOWhitelist until we find the one that is harmful in our system.

 

What is a useful goal for the user who needs to use this procedure?

Get back as many skip 1s as possible!

 

If I activate the DevirtualizeMMIO quirk and whitelist all areas by activating them, what happens?

First option:

- system starts properly!

Well you wasted a lot of time because you don't need this procedure! having all areas declared and activated in the config plist section Booter / MmmioWhitelist is like leaving the DevirtualiseMMIO quirk set to OFF.

Second option:

- system does not start properly!

Very well that's why you activated the quirk, if it were possible for us to keep everything unchanged we would not have activated the quirk.

So, with holy patience, they try to convert all the values one by one and insert them in MMIOWhitelist (skip 1) until they find those that cannot be inserted and that block your system.

 

At this point, if your ideas aren't more tangled up than when you started reading, you should ask yourself:

why do this operation of re-making available to UEFI Firmware as many areas as possible?

Simple, even if your PC starts and seems to work correctly only by activating the DevirtualiseMMIO quirk, during daily operation you could (certainly have) KP, Reboot problems or simply malfunctions of the Nvram and the sleep / wake cycle.

 

So it's a good thing to waste some time re-assigning them to free use of UEFI Bios until you find or find the ones that are impossible to reassign!

 

you can also find useful tip here:

https://www.macos86.it/topic/3307-trx40-bare-metal-vanilla-patches-yes-it-worksbutproxmox-is-better/?do=findComment&comment=85469

[Roy]

Hi fabiosun,

 

Thanks for your explanation. I only have one question:
Is this procedure good to do with all PCIe and M.2 devices installed or is it better to be as basic as possible?

 

 

[fabiosun]

It should be done with hardware you have mounted

and checking differences if you change your bios settings

there is no a better way

important is to check mmio values and if they change when you add or remove hardware

 

and imho and experience

if your system starts with devirtualizemmio quirk off

You could avoid to do this procedure

 

The area will be in the same number

only the values to convert could change with different mounted hardware or different bios option

Edited October 27, 2022 by fabiosun
Added some lines

[Roy]

Thank you!

 

I´ll check if my TRX40 start with that quirk in off. If doesn't start, I'll do the procedure.

 

 

[fabiosun]

8 hours ago, Roy said:

 

I´ll check if my TRX40 start with that quirk in off. If doesn't start, I'll do the procedure.

Roy, if you have a trx40 you must check that quirk on and create your MMIO whitelist 

For trx40 is mandatory to boot

 

if you like put your hardware in your  profile signature

and if you need use trx40 discussion to have help to configure it properly

 

Link to TRX40 discussion thread

 

[yandong31]

On 2/10/2022 at 12:34 AM, fabiosun said:

在这个线程中，我们将尝试解释这个非常有趣的怪癖的功能，以及最重要的是 MMIO 白名单的相关部分，这对于不同的系统来说更为重要。

该主题最近已在 OpenCore 配置 pdf 中以更详尽的方式记录下来，但如今，考虑到所使用的新 CPU 架构，让 Hackintosh 发挥其最大潜力已变得越来越有价值。

 

默认情况下，该怪癖是不活跃的，并且对于许多系统来说，让你的黑客工作和启动并不是必需的。

 

2019 年 12 月，随着第三代 AMD ThreadRipper CPU（sTRX4）的发布，许多用户不由自主地对该怪癖的功能产生了兴趣。

 

当时，OpenCore 关于该主题的文档还不是很详尽，因为它只对旧系统有用。

 

在 OpenCore 开发人员（我们始终要感谢他们的工作）有时提供的神秘帮助下，他们开始迈出第一步，了解如何使用它结合 MMIO 白名单功能在上述平台（sTRX4）上进行调试。

关联

 

通过激活怪癖并仅使用将 Misc / Debug / Target 选项设置为 67 的 OpenCore 调试版本，即使机器无法启动，也可以进行调试，其中突出显示 PC 的 MMIO 区域（区域数量和值可能会有所不同）：

08:808 00:001 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 0
08:809 00:001 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 0
08:810 00:001 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 0
08:811 00:001 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 0
08:812 00:001 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 0
08:813 00:001 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 0
08:814 00:001 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 0
08:816 00:001 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 0
08:817 00:001 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 0
08:818 00:001 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 0
08:819 00:001 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 0
08:820 00:001 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 0
08:821 00:001 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 0
08:822 00:001 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 0
08:823 00:001 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 0
08:825 00:001 OCABC: MMIO devirt 0x4040000000 (0x10400 pages, 0x8000000000000001) skip 0
08:826 00:001 OCABC: MMIO devirt 0x8BB0000000 (0x10400 pages, 0x8000000000000001) skip 0
08:827 00:001 OCABC: MMIO devirt 0x8BE0000000 (0x10400 pages, 0x8000000000000001) skip 0
08:828 00:001 OCABC: MMIO devirt 0xD750000000 (0x10400 pages, 0x8000000000000001) skip 0

 

尤为重要的是，即使在相同 BIOS 和制造商的条件下，这些区域也可能有所不同，但只能通过在 BIOS 中交换选项或以不同方式填充 nvme 和 pciexpress 插槽来实现。

笔记：

一个常见的错误是从任何配置中获取此列表并将其放入 config.plist 中

如果您更改 BIOS 中的选项或添加硬件，则必须始终在正在使用的系统中获取和计算它，并重新检查！

 

激活该怪癖涉及对内存区域进行非虚拟化 ，并且在某些情况下释放几兆字节的内存（通常为 64 到 256 Mb），这使得一些有问题的系统可以启动而不会在启动时出现臭名昭著的错误（内存分配错误），而这发生在启动的初始阶段。

 

skip 0 表示非虚拟化区域 ，如果 UEFI bios 在其内部操作期间需要该区域，而没有该区域可供使用，则会产生故障或内核恐慌。

 

根据 Opencore 开发人员的指示，我们专注于最后四个领域，它们在页面级别上最有可能被去虚拟化，并且有 16 种组合（4！）。经确认，当时使用的内核补丁在 sTRX4 系统上存在故障。现在我们先忽略这个说法，虽然它后来被证明并不完全正确，但事实上，它促使许多希望在其机器上使用 OSX 的 sTRX4 用户探索 ProXmox 虚拟化的迷人世界。

 

现在，当时进行的测试是报告最后 4 个区域以充分利用 OSX（跳过 1）的各种组合（16）。

如何？

在我们的 config.plist 的 Booter / MmioWhitelist 部分添加这些区域。为此，我们可以使用科学计算器或 HackCheck 下载区中的优秀应用（如图所示）进行下载，点击下方链接：

https://www.macos86.it/files/file/95-hack-check/

 

现在让我们只关注这个区域：

08:828 00:001 OCABC：MMIO devirt 0xD750000000（0x10400 页，0x8000000000000001）跳过 0

 

并取十六进制值 0xD750000000，这将转换为数字，如下图所示：

 

 

并且必须通过激活它来在 config.plist 的适当区域中准确报告：

 

 

保存 config.plist 并重新启动后，我们将在下一个调试日志中看到这种情况：

 

08:808 00:001 OCABC: MMIO devirt 0xE2100000 (0x81 pages, 0x8000000000000001) skip 0
08:809 00:001 OCABC: MMIO devirt 0xE3180000 (0x81 pages, 0x8000000000000001) skip 0
08:810 00:001 OCABC: MMIO devirt 0xEF100000 (0x181 pages, 0x8000000000000001) skip 0
08:811 00:001 OCABC: MMIO devirt 0xFA180000 (0x81 pages, 0x8000000000000001) skip 0
08:812 00:001 OCABC: MMIO devirt 0xFA300000 (0x100 pages, 0x8000000000000001) skip 0
08:813 00:001 OCABC: MMIO devirt 0xFEA00000 (0x100 pages, 0x8000000000000001) skip 0
08:814 00:001 OCABC: MMIO devirt 0xFEC00000 (0x1 pages, 0x8000000000000001) skip 0
08:816 00:001 OCABC: MMIO devirt 0xFEC10000 (0x1 pages, 0x8000000000000001) skip 0
08:817 00:001 OCABC: MMIO devirt 0xFED00000 (0x1 pages, 0x8000000000000001) skip 0
08:818 00:001 OCABC: MMIO devirt 0xFED40000 (0x5 pages, 0x8000000000000001) skip 0
08:819 00:001 OCABC: MMIO devirt 0xFED80000 (0x10 pages, 0x8000000000000001) skip 0
08:820 00:001 OCABC: MMIO devirt 0xFEDC2000 (0xE pages, 0x8000000000000001) skip 0
08:821 00:001 OCABC: MMIO devirt 0xFEDD4000 (0x2 pages, 0x8000000000000001) skip 0
08:822 00:001 OCABC: MMIO devirt 0xFEE00000 (0x100 pages, 0x8000000000000001) skip 0
08:823 00:001 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x8000000000000001) skip 0
08:825 00:001 OCABC: MMIO devirt 0x4040000000 (0x10400 pages, 0x8000000000000001) skip 0
08:826 00:001 OCABC: MMIO devirt 0x8BB0000000 (0x10400 pages, 0x8000000000000001) skip 0
08:827 00:001 OCABC: MMIO devirt 0x8BE0000000 (0x10400 pages, 0x8000000000000001) skip 0
08:828 00:001 OCABC: MMIO devirt 0xD750000000 (0x10400 pages, 0x8000000000000001) skip 1

 

因此，我们通过激活 YES 转换并插入到配置中的区域现在在配置中列为跳过 1。

这是什么意思？

这意味着现在该区域再次可供 UEFI Bios 使用，就好像我们没有激活该怪癖一样......但只有这个 MMIO 区域。

如果幸运的话，我们的系统无论如何都会启动并到达登录，那么我们可以继续插入并激活 MMIOWhitelist 中的所有其他区域，直到找到对我们的系统有害的区域。

 

对于需要使用此程序的用户来说，有用的目标是什么？

尽可能多地获取跳过 1！

 

如果我激活 DevirtualizeMMIO 怪癖并通过激活它们将所有区域列入白名单，会发生什么？

第一个选项：

- 系统正常启动！

好吧，你浪费了很多时间，因为你不需要这个过程！在配置 plist 部分 Booter / MmmioWhitelist 中声明和激活所有区域就像将 DevirtualiseMMIO 怪癖设置为 OFF 一样。

第二种选择：

- 系统无法正常启动！

很好，这就是你激活怪癖的原因，如果我们可以保持一切不变，我们就不会激活怪癖。

因此，他们以极大的耐心尝试逐一转换所有值，并将其插入 MMIOWhitelist（跳过 1），直到找到无法插入并阻塞系统的值。

 

此时，如果你的想法并不比开始阅读时更加混乱，你应该问自己：

为什么这个重新制作的操作要让尽可能多的区域可供 UEFI 固件使用？

很简单，即使您的 PC 仅通过激活 DevirtualiseMMIO 怪癖即可启动并正常工作，但在日常操作过程中，您肯定会遇到 KP、重启问题或 Nvram 和睡眠/唤醒周期故障。

 

因此，花一些时间将它们重新分配给可自由使用的 UEFI Bios 是一件好事，直到找到或找到那些无法重新分配的 UEFI Bios！

 

您还可以在这里找到有用的提示：

https://www.macos86.it/topic/3307-trx40-bare-metal-vanilla-patches-yes-it-worksbutproxmox-is-better/?do=findComment&comment=85469

Skip in MMIO devirtualisation means exactly what it says. It skips devirtualisation for the particular region found.

— If a region is whitelisted, then devirtualisation does not happen, and skip is 1.

— Otherwise the region is permitted to be used by the operating system, and skip is 0.

 

If you have suggestions on how to improve the debug message, feel free to let us know.

Edited March 4, 2020 by vit9696

 

What you're saying here is completely opposite to what vit9696 said. I don't know if more skips are better or fewer are better. In other words: are we picking the bad guys or the good guys here?

Edited October 18 by yandong31

[fabiosun]

@yandong31

if you read first post i put also a link here i was talking with vit and mhauser (download fritz)

where they said how to debug with mmio and quirk

so devitrualizemmio on produces all mmio skip to 0

enabling one mmio area to skip1 means what i said in the past

then if things are changed feel free to help to improve this old mmio talking😉

[yandong31]

@fabiosun  My understanding is that the DevirtualiseMmio quirk is designed to free up more memory address space for KASLR to use. However, some of these freed-up addresses might be problematic. The purpose of the MmioWhitelist is to filter out these specific problematic addresses.
Therefore, the MmioWhitelist shouldn't be considered "the more, the better." A longer list actually means less address space is ultimately freed up for KASLR. The correct approach is to only list the addresses that are genuinely harmful, preventing just those from being released.

[fabiosun]

@yandong31in my current platform you can see in my signature i skipped totally to build a correct MMIO withelist. on AM5 there are few area compared to trx40 platform and also using MMIO whitelist is pretty simple to have it working (only one must be reassigned to UEFI bios needs)

Only to my purposes and funny tests i use DisableWrite Variable quirks without building a MMIO Whitelist area and system is perfect in all its function (sleep, wake, reboot and so on)

 

with trx40 in the past we had to reassign more we can because we had many problem if we thought "less is better" (sleep, restart on shutdown and Nvram problems)

 

Devs documentation in this subject were initially few and cripticed (for non devs users) then (maybe) they clarified better also in opencore documentation (see where and when (Year 2022) this thread was born and see also their documentation in that time)

 

I had some chit chat (because i have zero skills to understand his friendly lecture) with Download Fritz about MMIO areas in others forum and he explained and clarified stuff about UEFI Bios and how this subjetct was involved in MMIO areas

Said this, thank you to renewing this old thread and i renew also the ask if you like to improve your finding in a detailed way i will very happy to add your experience in OP 😉

 

[yandong31]

@fabiosun  Your testing actually confirms my earlier point perfectly. DevirtualiseMmio works by freeing up more memory for the system to use. The reason you don't need a whitelist is that on your platform, all the memory it reclaims is perfectly usable.

However, if some of that reclaimed memory is faulty or problematic, you must use MmioWhitelist to skip over those specific bad regions to prevent system crashes. The trade-off is that the more entries you add to the MmioWhitelist, the fewer available addresses KASLR has to work with, which can cause its own set of problems.

So, I still believe the primary function of MmioWhitelist is precisely to identify and filter out the non-usable MMIO regions.

In my platform's case, there are four key regions. Skipping only the second one is sufficient for a normal boot. But given that regions three and four are quite small, I think including them in the skip is a viable approach.

21:417 00:057 OCABC: MMIO devirt start
21:430 00:013 OCABC: MMIO devirt 0xE0000000 (0x10000 pages, 0x800000000000100D) skip 0
21:443 00:012 OCABC: MMIO devirt 0xF7000000 (0x7E00 pages, 0x800000000000100D) skip 1
21:475 00:032 OCABC: MMIO devirt 0xFEE00000 (0x1 pages, 0x8000000000000001) skip 0
21:488 00:012 OCABC: MMIO devirt 0xFEE01000 (0x11FF pages, 0x800000000000100D) skip 0
21:544 00:056 OCABC: MMIO devirt 0x860000000 (0x20200 pages, 0x800000000000100D) skip 0
21:558 00:013 OCABC: MMIO devirt end, saved 806912 KB
21:570 00:012 OCABC: Only 128/256 slide values are usable!
21:602 00:031 OCABC: Valid slides - 128-255

 

[fabiosun]

2 minutes ago, yandong31 said:

The reason you don't need a whitelist is that on your platform, all the memory it reclaims is perfectly usable.

No

it is because i DisableWrite variable 

 

I have a question for you:

Devirtualize quirk ON

you have, let say ,5 MMIO area Skip to 0 in your opencore log

you reassign all of them and you see then all MMIO areas to skip 1

 

What does this mean? (related to DevirtualizeMMIO quirk)

 

[yandong31]

Put another way, enabling DevirtualiseMmio while whitelisting every MMIO region effectively neutralizes it, producing the same outcome as leaving it off.

[fabiosun]

on TRX40 more was better.

on AM5 this is not valid

On am5 i can reassign 4 of 5 MMIO areas, in this way my system loose is stability

I only reassign 1 area and system is perfect, or i use DevirtualizeMMIO and DisableWritevariable quirks without whitelisting any MMIO areas (not adviced but on AM5 it works as wit only a MMIO area reassigned.

 

No skill to understand if from 2022 opencore devs or motherboard Uefi firmware creators have changed something

Edited 1 hour ago by fabiosun
grammar

[yandong31]

Like I said before, with MmioWhitelist, more isn't better. If you skip 4 out of 5 regions, DevirtualiseMmio only reclaims memory from a single region for the system — and it's likely the smallest one. This can actually lead to system instability.

When it comes to the TRX40, the 'more isn't better' rule still holds true. However, the reason it might need a longer list is that the platform inherently contains numerous small or defective regions that must be filtered out.

Skip in MMIO devirtualisation means exactly what it says. It skips devirtualisation for the particular region found.

— If a region is whitelisted, then devirtualisation does not happen, and skip is 1.

— Otherwise the region is permitted to be used by the operating system, and skip is 0.

To be fair, vit9696 was very clear about this from the start.

[fabiosun]

19 minutes ago, yandong31 said:

In my platform's case, there are four key regions. Skipping only the second one is sufficient for a normal boot. But given that regions three and four are quite small, I think including them in the skip is a viable approach.

this is an extract of a my conversation with DF (in 2022)

You can try if your platform is an X870E to reassign first four and see if you have problem (Nvram, reboot, boot and so on)

Or you can disable MMIO whitelist and use only two quirks i said

I am pretty sure your system beahviour will be the same!

In the past DF said me MMIO areas are not OSx related but Uefi firmware related (and i respected his words)

 

Ps, i do not have to convince you more or less is better..i have only proposed my experience in a platform that initially was not supported by opencore 😉

 

 

 

[yandong31]

Just to be clear for anyone else referencing this: for my platform, I only needed to skip Region 2 to get everything working normally. I'm not replying because I have a problem, but to serve as a reference for others — don't fall into the trap of thinking that skipping more regions is always better.

To be clear, my view might not be entirely correct either. Let's discuss it and allow everyone to judge for themselves. Regardless, I really appreciate your contributions on the forum.

[fabiosun]

Thread was created to have a place to discuss freely on this subject, so also your opinion is important and will be useful to other

 

In your test (if you like try to disable MMIO whitelist and use the quirks i said

In my opinion your system will be working in the same way!

 

PS: you platform (if it is x670E/X870 E) need only that second area Skipped to 1 (you can check many EFI you see in international forum)

Trx40 was different

 

 

[yandong31]

You're right, I only need to skip Region 2 to boot. However, since Regions 3 and 4 are quite small, I'm thinking that skipping them as well might improve system stability. I'm testing that theory now.