カーネル読み込みメモリ空間を確保する (OpenCore編)

　今(2020-11-30)、MMIOについて、TRX40で動かしている、iCanaroさんが、Clover General DiscussionでAMDで動かすにあたって重要だ（いくつか設定している）とのコメントがありました。この項目については、どうも謎も多いようです、OCでも、OC Integreted Cloverでも動作は同じなのですが、Z390のある会社のＭＢでは、項目があること自体で不安定になるような記述も見受けられます。わたしも、理解したいですねぇ。

config.plistでDevirtualiseMmioをtrueにする
の意味がわかりました。私のところだと、ログが流れて、検索にも向かないので、できればこちらで、まとめてくださると嬉しいです。
私が質問したのは概ねこういうことです。
メモリを仮想化すれば、混んできたときに再配置（リアロケーション）することで、メモリを空けられるのが、仮想化の1つの利点、だとすると、MMIO（メモリマップドI/O）も仮想化してリアロケーションしても仮想アドレスから使えるのなら、Devirtualise（仮想化しない）のは混乱します。
　ここで、なんと、Clover General DiscussionにOpenCoreのDeveloper、Download-Fritzを召喚してしまいました＾＾；ｗｗ
　@Alpha999 “Virtualisation” here is not about CPU virtualisation (VT-x, VT-d) but memory virtualisation (page table stuff). Yes, one of the advantages is you can physically move memory and still keep the addresses the same. MMIO virtualisation makes little to no sense (MMIO cannot be relocated with just virtualisation, so no, it does not make anything more difficult, and afaik nobody does this anyway). The issue is Apple reserves memory for virtualised memory whether it is moved by boot.efi or not, so useless (literally unused) virtualised MMIO space increases the initial kernel memory.
　中で言ってることの、話では、「MMIOの仮想化はほとんど意味がありません（MMIOは仮想化だけでは再配置できないため、これ以上難しいことはありません。とにかく誰もこれを行いません）」つまり・＜仮想化に意味はなく、仮想化をともめても、だれもそのリアロケーションをしないので、カーネルから（ナノカーネルならユーザ領域に含まれてる権限もあるかも）利用自体に支障をきたすことがほぼない機能＞なのです。
　そして、仮想化MMIOにするために更に（実際は仮想化は使われていないのに・・・ここでは文字どおりunused）仮想化用のメモリが利用されているため、仮想化をやめることで、カーネルをロードできるメモリを増やすことができるということです。（メモリオーバーヘッド（なんかオーバーヘッドと言うと負荷の方を考えがちなので言い方は良いのかしら？）という意味ではBootmacOSさんの言うとおりだと思います）
　そのあと、「上の理解で正しいですか？」に加え、
「非仮想化を行うと動かない部分についてWhiteLitstを使うんですね」
で、Frizから、Likeがついたので、これで間違いないと思います。
　

つぎにバーチャルメモリ、仮想メモリとその動作について、誤解を恐れないで（広義の仮想化について）簡単に書きます。
　仮想化は歴史的に言うと、みんなが物理（本物のDDRとかの）メモリを使いたいけど、物理メモリは高くて少量しか使えないので、仮想的（絵空事で）に広大なメモリ地図をみんなには見せておいて、実際にはメモリに置く置き方等や、いらない部分はディスクにいったん退避してもらって、みんなで大きなメモリ地図を自由に使おうということから始まります。

　３．スワップ・・・置換。何らかのアルゴリズム（計算の手順・やり方）で、あまり使わない（実行しない）プログラムの一部分を、より遅くて安い記憶装置（例えばHDD等）に記憶させてしまい。もっと頻繁に動く部分のプログラムを残しておくこと。あまり実行しない部分はよけて置けるので、今今実行しないといけないプログラムの部分を物理メモリに残します。頻繁でないところを後になって使うときには、単純に言えば実行するときにHDD等から取り出して、実行すればいい。
　４．リエントラント・・・再入可能、同じプログラムを動かすときに、同じプログラムを物理メモリにおいて効率的でしょうか？プログラムの作り方として、1つの物理メモリに置いておいて、実行をもう一度してもデーターがこんがらがらないようになっていれば、同じプログラムは1つだけ物理メモリに置けばいいのです。
（２と４は、ちょっと仮想化から外れメモリ管理やプロセス管理だと思いますが、仮想化されているため、さらにこういう方法で物理メモリを効率よく利用しているということです。）

　さて、そこで、ようやく仮想MMIOです。
○仮想化MMIOはプログラムと違って、スワップはできないし、リアロケーションからできるコンパクションもほとんど全くといいほど使えないし使われてない。そのために仮想化する分（仮想化管理用に）MMIOはメモリを食っているので、仮想化をやめてそれを使えるようにしてる。
○一部、AMDでは、仮想化しておかないと動かないものがあるのでWhite Listで残せるようにしたということです。
　自分でも間違えがありました、リアロケーションとコンパクションは、意識して使わけないと、いけません。失礼しました。

おつかれさまです。
わたしも、資料探しで、眠くなって仮眠をとっちゃいました＾＾；
えーと、すいませんでした。用語は上の通り訂正します。
で、えーとそれから、正しくは
仮想記憶とは、アドレス変換（物理と仮想での）とスワッピングのことですね。
https://www.pf.is.s.u-tokyo.ac.jp/wp-content/uploads/2018/06/OS_08.pdf
勉強になりました。

　ここから先にあまり書かれてるものがないですね。とくにコンパクションをアドレス変換でやっちゃうってことなんですが・・・
　えっと整理させてください。

　２．アドレス（マップ上の置き場所の）変換・・・上のようにHDDにもプログラムを置けるので、みんなで使う大きなメモリマップ（仮想メモリのメモリマップ）を作り、物理メモリの置き場所に変換するということです。今の主流のやり方は、簡単に言うと、仮想・物理メモリを、ある程度区切っといて（多くは４KB)、どれとどれを結びつけるかで決めます。
　さらに、物理メモリからスワップしまった部分（１でスワップした部分はHDD等のどこにあるかを記録しておき、物理メモリのないとわかった段階でHDD等から取り出してきます）
　肝は、物理アドレスのどこにおいてあっても、論理アドレスから見ると同じアドレスに見えるということです。（後でこれがコンパクションのときなどに効いてきます）。

　２．リエントラント・・・再入可能、同じプログラムを動かすときに、同じプログラムを物理メモリにおいて効率的でしょうか？プログラムの作り方として、1つの物理メモリに置いておいて、実行をもう一度してもデーターがこんがらがらないようになっていれば、同じプログラムは1つだけ物理メモリに置けばいいのです。　

　そこで、１．リロケータブルでの「プログラムが、物理メモリのどこにおいてもいい（実行できる）」という性質を使って、物理メモリ上に、きっちり詰め替えるのです。（HDDで言うデフラグメントと同じです。空き（利用できる）領域がフラグメントする（断片化する）のでコンパクションをして領域を確保するのです）

　つまり、逆に言うと、仮想メモリで、アドレス変換したことについて、スワップばかり目が行きがちですが、仮想アドレスが変わらないのでうまくコンパクションできるというところもあるというわけです。（これで正しければいいのですが、誰かご存知方がいれば教えて下さい）

BootMacOsさん。
すみません、かなり、コメントを汚してしまったのを謝ります。
本編はまとめて、こっちに書きました。
Couldn’t allocate runtime areaエラーと、デバイス、メモリ管理のこと
https://mifmif.mydns.jp/alpha/?p=1006
ここでは、簡単にまとめていただいて、詳しくはリンクを降ってもらえると、みなさんのためになるかなぁと思います。
よろしくおねがいします。

　すいませんが違うんです。ごめんなさい。VT-dは仮想マシン（バーチャルマシン用の仮想化を意味するのであって、仮想メモリを意味するものではありません。

　VT-d
ダイレクト I/O 向けインテル VT(Intel VT-d)[3] とは、I/O処理の仮想化を支援する機能。VT-dなどのハードウェア的な仮想化支援が無い場合、仮想マシンモニタは、I/Oデバイスをエミュレートし、DMAのメモリ領域のリマッピングを行う必要がある。VT-dでは、ハードウェア的にDMA転送時のリマッピングを行うようにする。この場合、通常のデバイスドライバを使用することができ、利便性や性能が向上することになる。 メモリアクセスはチップセット側の機能であるため、次世代のチップセットで対応する予定である。Intel 3シリーズチップセットでは違う容量のDRAMメモリを混載した場合に問題が出るため利用ができない場合がある。

　この場合の「I/O処理の仮想化」とは、バーチャルマシンへ仮想してみせることを意味しています。
　バーチャルマシン向けにVT-dを使って仮想化しない場合、仮想元のOS上でI/Oデバイスのメモリ領域をバーチャルマシン向けに用意しないといけません。DMA=ダイレクトメモリアクセス（CPUによらないでI/Oとメモリが転送し合う技術）についても、バーチャルマシンにはCPUに依存してないように見せかけないといけないので、仮想元OS上で、メモリがあるように（リマップ＝置き直して）見せないといけないということだとおもいます。

　わたしも最初はこれかもと思って聞いたんですが、明確にDownload-Frizに違うと言われています。
@Alpha999 “Virtualisation” here is not about CPU virtualisation (VT-x, VT-d) but memory virtualisation (page table stuff). Yes, one of the advantages is you can physically move memory and still keep the addresses the same. MMIO virtualisation makes little to no sense (MMIO cannot be relocated with just virtualisation, so no, it does not make anything more difficult, and afaik nobody does this anyway). The issue is Apple reserves memory for virtualised memory whether it is moved by boot.efi or not, so useless (literally unused) virtualised MMIO space increases the initial kernel memory.

とにかく、お返事ありがとうございました。

お疲れさまです。
忙しそうなので、こっちを汚すのもなんですので、時間のある時でいいので、向こうに忌憚なく書き込んでください。長めに待ってます。
文面や言い方が悪い場合、是非とも直していきたいと思います。
また、こちらの要約も、是非とも皆さんのために、適切であることを願っています。
向こうでは、意見について集約し、直して良ければ（OK貰えれば）、コメントは外していこうと思います。
Couldn’t allocate runtime areaエラーと、デバイス、メモリ管理のこと
https://mifmif.mydns.jp/alpha/?p=1006
もし、表現や問題の採用方法に、問題があれば、率直に謝罪します。申し訳ありません。
　ただ、純粋に技術的範疇なので、物理的制約と、技術的なドキュメントに沿って話をしないと、（OSの開発のように思想を含むように・・・思いを含みたいのは非常にわかるのですが）大変申し訳ありませんが、自然科学を逸脱してしまうので、どうしてもできません。ご理解いただけるとありがたいです。

>Frizの答えに戻るべきだと思います。
仮想化技術について話てる訳では無くて「Apple(MacOS)が使いもしない仮想化領域を確保する為に
この領域を解放して起動メモリを増やせる」と理解しています。
(page table stuff) については Alpha さんもbootmacosさんも同じ事を言ってる様に思えます。
page = プログラム実行限界
table = page 定義配列
staff = 楽譜の五線の意味ですが、ここではアドレス空間の事
こんな理解で正しいでしょうか？

Hello, developers.

I would be happy if you could educate me.

We discussed and studied together at a Japanese forum.
Is the idea of devirtualized MMIO like the following?
(I think UEFI is a great standard!)

The application area is, of course, on the virtual memory address derived from the XNU kernel. Also, since it is a hybrid kernel, the driver is also included, and it runs within the virtual memory address itself, and access to IO is realized as access to the IO instance of the class by IO Kit.

After the initial kernel ran, memory, IO and other configurations were completed, and the XNU kernel itself is at its own virtual memory address (because it is a kernel, it is naturally protected by protected mode memory). And the driver uses the IO Kit to access the IO.

However, before loading the kernel, it is managed by UEFI BIOS, so the firmware is in the virtual address map derived from UEFI. First, PCIe x’s MMCONFIG is on the memory map. Furthermore, since UEFI is in Identity Mapped Paging mode as it is, the MMCONFIG area is also virtualized with RUNTIMEBIT set. This is useless, so it can be devirtualized and the page can be in physical memory, giving you more space for the initial kernel.
However, depending on the CPU, Cipset, and device, the firmware may require a virtualized address map derived from UEFI, so it is necessary to put it in the Whitelist and virtualize it.

Thank you in advance for spending your precious time.

お疲れ様です。
ひとまず、こちらの方は、終わりました。
ご対応の程、よろしくお願いします。
話合いの場であると理解しています。
無視せずに、ご誠実に対応をお願いします。
よろしくお願い致します。

BootmacOSさん、その手を使うのはよしましょうよ。
もし、BootmacOSさんでないから、消したげてくださいね。そして、IP設定もお願いしますね。WordPressなんですからやり方は知ってますので。
そして、謝罪します。
そもそも、BootmacOSさんが情報ほしいっていうし、Asuralの話があるんで、間違えは直して書き直してるんです。
　理解できないっていうから、書き直して、メモリマップの件も足してるんですし、質問を受けて（ですから全然下手に出てますよね）、解りやすく書き直して、こちらのネタの足しになればと思って動いてるんですよ。
　正直に言うと、コンパクションの話以来、こっちの話にまともに応答してくれてないですよね。
そのあと、こっち側で、解りやすくしてくれっていうから、徹夜で調べ上げて、書き直してるんですけど、もし、BootmacOSさんがこんな方法で、黙らせようとしているなら（そう思いたくないので対応してほしいんですが）、事実があって説明もつくすって言っているのに、あまりにもひどくないですか？
　逃げも隠れもしません。対応する時間に差があるのは仕方ありません。私だって仕事しながら、全部調べてるんですよ。
　対応しないのであれば、匿名さんとやらについては、申し訳ないですけど、BootMacOsと思わせてもらって、どんどん場が荒れるだけです。
　コンパクションの話以来、内容に触れないのはBootmacさんですので、こちらは下手に出て、調べ上げてかき直してるんです。
　匿名さんが来る限り、どんどん対応していきますよ。
よろしくお願いします。

お疲れ様です。
BootmacOSさん、最後の1つです。（私も書くの忘れてたんですが）
「通常はMMIOにも論理アドレスを与えて（仮想化して）、論理アドレスからMMIOを使用できる状態にするようです」
でなく、
「普通のOSとかは仮想アドレスをMMIOには与えないのに、EFI（OpenCore）が動くときには、BIOSということもあって、特別に（この時だけ）MMIOが仮想メモリマップに入れられてるんです。
だから、普通のOSだと、仮想化を全然しないので、MMIOのところをメモリにしちゃって良いってことになります。」
よろしくお願いします。
ちょっと、図の方も直してみます。