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

macOSが起動する時、ブートローダがカーネルをメモリに読み込みます。この時、連続した十分な大きさのメモリ領域が確保できないと、起動に失敗して禁止マークが出ます。この状況への対処方法が、OpenCoreではCloverよりも充実しています。

以前の記事では、メモリの使用状況(メモリマップ)を確認して、空き領域を起動オプションのslide値で指定することで、カーネル用メモリを確実に確保する方法を紹介しました。今回はそのOpenCore編です。


以下のOpenCoreのガイドで、この問題への対処方法が詳しく説明されています。以下はこのサイトの抄訳です。

KASLR Slide値を設定する

このページでは、 “Couldn’t allocate runtime area” (ランタイム領域を割り当てられませんでした) というエラーを理解し、修正したいユーザーのために説明します。これは Z390, X99, X299 などで最もよく現れるエラーです。このページはOpenCoreだけでなく、Cloverも対象にします。

KASLRとは何か?

KASLRは、Kernel address space layout randomizationの略で、セキュリティ目的で使用されます。これにより攻撃者がメモリ内の重要なオブジェクトがどこにあるのかを把握するのを難しくします。

HackintoshでKASLRが問題になるのは、マザーボードに連続した十分なサイズのメモリー空間がなく、カーネルが完全に収まらない場合です。そこで、slide=xxx を使って、KASLRをキャンセルしてメモリーアドレスを固定していました。このパラメータを設定すると、macOSに起動ごとに動作するランダムな領域にカーネル読み込む代わりに、動作することがわかっている場所を使用します。

このガイドが必要な人達

カーネルを読み込むメモリ空間が足りなかったり、細分化されたメモリー空間に読み込み場所が移動してしまったユーザーのためのガイドです。その場合、このようなエラーが出ます。

Error allocating 0x1197b pages at 0x0000000017a80000 alloc type 2
Couldn't allocate runtime area

以下のようなエラーが出ることもあります。

Only 244/256 slide values are usable!

または、macOSの実行中にカーネルパニックが発生することもあります。

panic(cpu 6 caller 0xffffff801fc057ba): a freed zone element has been modified in zone kalloc.4096: expected 0x3f00116dbe8a46f6 but found 0x3f00116d00000000

これらのエラーの1番の特徴は、発生にランダム性があることです。大抵は20回も起動を繰り返せば、1回くらいはエラーを出さないで起動します。

問題解決の方法

これを修正するのは非常に簡単で、その手順はCloverユーザでもOpenCoreユーザーでも同じです。Clover ユーザに必要なものは以下です。

  • Clover Shell : shell64.efi などと呼ばれているファイルを、EFI/CLOVER/tools の下に置きます。
  • OcQuirks : Aptioの修正、OsxAptioFixDrvX, AptioMemoryFixなどと混在させないでください。このガイドでは OcQuirks のみサポートします。EFI/CLOVER/drivers/UEFI の中に置きます。
  • OpenRuntime.efi : OcQuirksのパッケージに含まれます。EFI/CLOVER/drivers/UEFI の中に入れます。
  • OcQuirks.plist : (これもOcQuirksに含まれてます) EFI/CLOVER/drivers/UEFI の中に入れます。

一方、OpenCoreユーザに必要なものは以下です。

  • OpenRuntime
  • OpenShell これをconfig.plistのRoot -> Misc -> Toolsで有効にしておきます。

そして、config.plist -> Booter (OpenCore用) かOcQuirks.plist (Clover用) で以下の設定をします。

  • AvoidRuntimeDefrag: YES
    日付、時刻、NVRAM、電源制御などのUEFIランタイムサービスの修正
  • DevirtualiseMmio : YES
    Stolen Memory のサイズを削減し、slide=N値のオプションを拡張し、Z390のメモリ割り当ての問題を修正するのに非常に役立ちます。
  • EnableSafeModeSlide : YES
    slide 値をセーフモードで使用できるようにします。
  • ProtectUefiServices : NO
    UEFI サービスがファームウェアによってオーバーライドされないように保護します。主に VM、300 シリーズ、および Ice Lake や Comet Lake のような新しいシステムに関連します。
  • ProvideCustomSlide : YES
    これにより、カーネルが、読み込みに適してメモリー空間のみを選択し、起動に失敗する可能性のある場所を避けるようになります。読み込み場所のランダム性は維持していますが、ランダムに選択する際に、不適切なメモリ領域を除外するようになります。(訳注:これが従来のslide設定の役割を果たしてくれるようです。ただし、slideを固定するのではなく、使用可能なslide値を自動で探して、その中からランダムに選んでくれているようです。)
  • RebuildAppleMemoryMap : YES
    macOSと互換性のあるメモリマップを生成します。いくつかのラップトップのOEMファームウェアで失敗することがありますので、早期段階でブートに失敗する場合は、これを無効にします。

BIOS設定

BIOSを以下のように設定します。

  • BIOSを更新する (初期のBIOSにはメモリマップの問題があることが知られているので、非常に重要です, 特にZ390で重要です。)
  • CMOSを工場出荷時設定にリセットする
  • とても必要とされる以下のBIOS設定をします。
    Above4GDecoding : 有効にします。デバイスが4GB以上のメモリ領域を使用できるようになり、macOSカーネルが収まるメモリー空間が増えます。
    Boot Options -> Windows8.1/10 mode : これにより古いレガシーなゴミのようなコードがロードされなくなります。誤解されがちですが、other OSというもう一つの選択肢は、古いバージョンのWindowsを起動するための選択肢であり、LinuxやmacOSのための選択肢ではありません。(訳注:ASUSのZ490マザーボードにCatalinaを入れたマシンでは、other OSにしないと起動しませんでした。)
  • BIOS内の不要なデバイスをできるだけ多く無効にします。これにより、、起動時のマップの細分化がが減少するので、起動失敗の可能性が減ります。
    CSM : 無効にします。有効化してしまうと、レガシーサポートのため、不要なゴミの束が追加され、またUEFIシェルが起動できなくなります。
    Intel SGX : 無効にします。SGXとはSoftware Guard Extensionsの略です。有効にしても、多くのメモリ空間を占有するだけで、macOSでは何もしません。
    Parallel Port と Serial Port:無効にします。macOSではParallel portは認識しませんし、Serialを必要とする人はいないです。
    iGPU : やむを得ない場合は、これを無効にすることで、メモリを大幅に解放できます。
    Thunderbolt : 無効にします。ほとんどのマザーボードはTBを搭載していませんし、搭載していても使用しないなら、無効にすることでメモリ空間を確保できます。
    LED ligiting : 無効にします。もう光らせなくても良いでしょう。
    Legacy USB : 無効にします。これもレガシーなガラクタです。

テストブート

上記のように、EFI、config.plist、BIOSの設定を調整したら、これで起動を試してください。これでめでたく解決したら、この先の作業は不要です。まだ問題が発生する場合は、次のステップで、もっとディープな作業、つまりslide値の計算をしましょう。

slide値を探す

ブートマネージャでEFIシェルを開き、memmapを実行します。すべてのページとそのサイズのリストが以下のように表示されます。ここからが楽しみの始まりです。

Type      Start            End              # Pages          Attributes
RT_Data	  0000000000000000 0000000000000FFF 0000000000000001 800000000000000F
Available 0000000000001000 0000000000057FFF 0000000000000057 000000000000000F
Reserved  0000000000058000 0000000000058FFF 0000000000000001 000000000000000F
Available 0000000000059000 000000000008FFFF 0000000000000037 000000000000000F
RT_Code   0000000000090000 0000000000090FFF 0000000000000001 800000000000000F
Available 0000000000091000 000000000009DFFF 000000000000000D 000000000000000F
Reserved  000000000009E000 000000000009FFFF 0000000000000002 000000000000000F
Available 0000000000100000 000000005B635FFF 000000000005B536 000000000000000F
BS_Data   000000005B636000 000000005B675FFF 0000000000000040 000000000000000F
Available 000000005B676000 000000006AF77FFF 000000000000F902 000000000000000F
LoaderCode000000006AF78000 000000006B155FFF 00000000000001DE 000000000000000F
BS_Data   000000006B156000 000000006B523FFF 00000000000003CE 000000000000000F
ACPI_NVS  000000006B524000 000000006B524FFF 0000000000000001 000000000000000F
BS_Data   000000006B526000 000000006B625FFF 0000000000000100 000000000000000F
Available 000000006B626000 000000006B634FFF 000000000000000F 000000000000000F

(訳注:このあと、slide値を決める手順が書かれています。どういうわけか、一番高い番地のAvailableを第一候補として〜15ページしかないのに〜、slideが255を超えるので諦めて、順当に0x100000番地からの領域、すなわちslide=0を選択しています。ということで少し遠回りしている感じもしますし、また、こちらで解説した内容と同じなので省略します。またRedditの/r/hackintoshのdiscordにもツールらしきものがあるらしく、その説明もありますが、これも省略します。)

DevirtualiseMmioを使う

訳注:この先はあまり理解できませんでした。推測を交えて内容をまとめると、次のようなことだと思います。推測部分は間違っているかもしれません。

config.plistでDevirtualiseMmioをtrueにする

DevirtualiseMmioのデフォルトはfalseですが、これをtrueにします。これにより、カーネルを読み込む場所のメモリー使用が64から256MB程度節約できて、KASLRの失敗を防止できます。

MMIOはMemory Mapped IOのことです。入出力デバイスのコントロールをメモリーのアドレス線を利用して行うのがMMIOです。上でのべたEFI Shellのmemmapコマンドによると、E0000000番地からFFFFFFFF番地までの512MBにMMIOが割り当てられています。インテルチップセットのマザーボードなら同様のようです。この番地には、メモリーが割り当てられていたとしても、IOへのアクセスになってしまい使えません。

Type Start            End              # Pages          Attributes
MMIO 00000000E0000000-00000000EFFFFFFF 0000000000010000 800000000000100D
MMIO 00000000FE000000-00000000FE010FFF 0000000000000011 8000000000000001
MMIO 00000000FEC00000-00000000FEC00FFF 0000000000000001 800000000000100D
MMIO 00000000FED00000-00000000FED03FFF 0000000000000004 800000000000100D
MMIO 00000000FEE00000-00000000FEE00FFF 0000000000000001 8000000000000001
MMIO 00000000FF000000-00000000FFFFFFFF 0000000000001000 800000000000100D

(以下はフォーラムで教えていただいた図をもとに考えた説明です、間違っていたらすみません)EFIによってOSが起動する際に、通常はMMIOに論理アドレスを与えて(仮想化して)、論理アドレスからMMIOを使用できる状態にするようです。ただMMIOの仮想化を行わなくても(de-virtualiseしても)、物理アドレスにアクセスできるプロセスからはMMIOを使えるのでそれほど問題はないようです。MMIOを仮想化しない場合は、MMIOの部分もメモリーにマップできるので、64MBから256MBの空き領域が稼げるようです。DevirtualiseMmioフラグをtureにすると、カーネルが読み込まれる領域を少しでも多く確保できるので、起動失敗の確率を下げられます。

Kaby Lake以前のCPUでは、デフォルト通りfalseが、Coffee Lake, Comet Lakeなどではtrueにすると良いとされていますが、手元のCoffee Lake-Sではfalseでも動きました。通常はfalseで、起動失敗する場合にはtrueを試すのが良いと思います。

ちなみにどうでも良いことですが、virtualize (仮想化) をvirtualiseと書くのは英国風らしいです。

config.plistにMmioWhitelistを指定する

DevirtualiseMmioをtrueにした場合に、メモリは節約できるものの、Threadripper TRX40 19H などの一部のシステムで起動しなくなることがあるらしいです。そのような場合、DevirtualiseMmioを適用しない領域を指定するのが、これがMmioWhitelistです。これの作り方について説明がありますが省略します。ほとんどのシステムではMnioWhitelistは不要とのことです。

ここまでが抄訳です。


結局どうしたら良いのか

OpenCoreでどう対応すべきかについてまとめます。上記のガイドでは、slide値を求める方法は書いてありますが、ブートオプションなどで設定する方法にまでは書かれていませんでした。当然のことで省略されたのかもしれないですし、slideを使うことをあまり推奨していないのかもしれません。

OpenCoreのReference Manual (0.5.8) の最初の方(15ページ)には、最初にすべきことの一つに、「slideを使うな」と書いてあります。config.plistの設定からも、NVRAMのboot argumentからも削除しておくようにとのことです。そして、「No slide values are usable! Use custom slide!」というエラーが出てから検討してくださいとあります。slideは、KASLRを回避する上、SIPを緩める必要があるので、セキュリティに影響を与えるという考えなのかもしれません。まずはslideを使わなくても済む方法を試みて、それでもダメな場合だけにslideを使いましょうとの方針だと思います。

ということで、このガイドのステップをまとめると、以下になります。まずはマザーボードの設定です。

  • BIOSを更新する
  • Above 4G Decodingを有効にする
  • CSMを無効にする
  • Boot Options -> Windows8.1/10 mode にする(訳注:前述のようにother OSを選択しないと起動しないことがあります)
  • Parallel Port と Serial Portを無効にします

可能ならば以下も設定します。

  • Intel SGX : 使用していないなら無効にします。
  • Thunderbolt : 使用していないなら無効にします。
  • LED ligiting : 無効にします。
  • Legacy USB : 無効にします。

そしてconfig.plistで以下のように設定します。

  • AvoidRuntimeDefrag: true
  • DevirtualiseMmio : true
  • EnableSafeModeSlide : true
  • ProtectUefiServices : false
  • ProvideCustomSlide : true
  • RebuildAppleMemoryMap : true

設定は、環境に合わせて必要なものを選択して、正常に起動するまで少しずつ足して行くのが良いと思います。

まとめ

KASLRに関係した理由でmacOSが起動しないことへの対処法を紹介しました。基本的には、メモリー空間を確保する処置をして、KASLRの選択範囲を狭めることで対応しています。BIOS設定とOpenCoreの機能で大体の場合に対応できて、slideによるカーネル読み込み番地固定は最終手段のようです。

88件のコメント

  1. いつも参考にさせていただいてます。
    なんとかヴァニラな状態で起動するマシンができたのですが、CPUを9100Fから9400に交換しようとしたら起動しなくなりまして、、、
    何かお知恵をいただければ幸いです。

  2. まだまだHackintoshビギナーですが、9100F→9400であれば、大きな違いはiGPUの有無なので、そこに関わりそうなところだと、BIOSの設定、Lilu、WhateverGreenを最新Verにするとかでチェックしてみてはいかがでしょう?

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

  4. お疲れさまです
     iCanaroさんが、Clover General Discussionでいうには、OpenCoreのDebugバージョンで完全にリストアップし、アドレス値を10進数に直して書き込みます。とありました。どうやら、MMIOはやはり、BootmacOSさんの言う通り、メモリマップドIOのことで、リストが出たもののアドレスを変更する必要のあるときに使うようです。

  5. config.plistでDevirtualiseMmioをtrueにする
    の意味がわかりました。私のところだと、ログが流れて、検索にも向かないので、できればこちらで、まとめてくださると嬉しいです。
    私が質問したのは概ねこういうことです。
    メモリを仮想化すれば、混んできたときに再配置(リアロケーション)することで、メモリを空けられるのが、仮想化の1つの利点、だとすると、MMIO(メモリマップドI/O)も仮想化してリアロケーションしても仮想アドレスから使えるのなら、Devirtualise(仮想化しない)のは混乱します。
     ここで、なんと、Clover General DiscussionにOpenCoreのDeveloper、Download-Fritzを召喚してしまいました^^;ww
     @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がついたので、これで間違いないと思います。
     

  6. Alphaさん、ありがとうございます。補足と整理をしてみました。合ってますでしょうか?

    仮想メモリーは、使用頻度の低いメモリーをHDDに書き出して(ページアウトして)、使う時にHDDから読み出してメモリーに書き戻して(ページインして)、その結果、たくさんメモリーがあるかのように見せる手法。

    MMIOは、ハードウェア(IO)の内部メモリーやレジスターやポートなどを、メモリー番地にハード的に配線して割り当て(メモリーマップ)て、メモリー読み書きのようにして、IOにアクセスする方法。

    なのでMMIOを使うときは、メモリーの物理番地に意味があるので、MMIO領域はページアウトできない。仮想メモリを使うとしてもMMIO領域はページアウトしない設定で使う。macOSも(多分)MMIO領域はページアウトしないけど、仮想メモリーのために使いもしない作業領域を確保してしまいこれが無駄(オーバーヘッド)になる。なので仮想メモリーを使わないと宣言することで無駄を減らして、その分、実メモリーを確保できる。

  7. お疲れ様です
    仮想化では、HDDへのページイン ページアウト(スワップイン スワップアウト)の前に、リアロケーション(物理メモリマップ内での再配置)がおこなわれています。プログラムでもそうなんですが、最初からぴっちり並べません(特にプログラムだと前に起動していたものをキルすると、利用しなくなった、利用可能でも、大きさがまちまちで、いわゆる飛び地見たいになったメモリがマップ内にできます。)
    ちなみに、こういう、リアロケーションをうながすのが、メモリクリーナーです。

    さて、memmapで見たように、MMIOもまた、飛び地でできます。そのために、まとまったカーネル領域を確保出来ません。だとすれば、一見MMIOも仮想化されているので、リアロケーションして、まとめてしまって、カーネル領域を作ればいいと思うのが筋ですし。絶対出来ないのでないようです。
    しかし、メモリにプログラムを配置しただけの仮想化とちがって、MMIOをリアロケーションする作業は困難なので、誰もやりません。(きっとパソコンを動かすのには面倒すぎて、osですらその作業を行わないのでしょう)
    このようにして、行わない、MMIOの仮想化機能をいれていますが、実はそのためにMMIO領域がある程度の量使われています。
    そのため、仮想化を辞める(デバーチャライズ)すると、全くほとんど利用の便を失うことなく、メモリマップから仮想化に必要だったMMIO領域を解放できます。
    そのため、カーネルが入ることの出来る連続した領域を確保出来るようになります。

    一見MMIOもヴァーチャライズしているので、リアロケーションしてカーネルを入れる連続領域を確保できると思いますがプログラムと違い簡単にはリアロケーション出来ないので誰もしません。だから、デバーチャライズでバーチャライズに使ってたMMIO領域を減らせます。そして、カーネルを置く場所を増やせるということです。
    ただ、AMDのプロセッサではこの機能を全面的に無くすと動かないデバイスが有るので、white listで一部でこの機能を無くさないようにしています。

    こんな感じでどうでしょう。どこか解らない部分があれば言ってください。

    お願いします

    1. お疲れ様です。
       MMIOは、いまでも、アセンブリ言語からみて、CPUのメモリバスに、IOを配線して付けたようになっています。
       (でも、そもそも、80系は、MMIOでなかったはずです、IO専用にアドレスがるようなバスがあったので、ISAのようなデバイス用のバスがあったと思います。https://linuxjf.osdn.jp/JFdocs/ISAPnP-HOWTO-11.html)
       PCIバスとDDRメモリくらいからだと思うのですが、内部バスを色々別にして、早さを稼ぐようになりました、そこで、内部のバスとPCIバスをつなぐのがブリッジです。アセンブリから見るとあたかも、IOがメモリ内にあるように見えますが、実際にはPCIバスにつながったデバイスは最初にBIOSがブリッジを使ってPCIカードを調べてメモリを割り付けて決めています。
      http://www.interface.co.jp/download/tutorial/tut0008_11.pdf
      なので、配線から理解というのは正直なかなか難しいです。
      ええっと、なんていえばいいのか、もっと理系的な意味で抽象化(すべて具体に還元できる)ようにできているんですね。
      そして、Linuxのような、OSのカーネル自体もPCIのメモリを再配置するようです。
      http://archive.linux.or.jp/JF/JFdocs/The-Linux-Kernel-7.html
      ・・・・
      ちなみに
       もっと単純にした方が早いんでないのかと言えばそうなんです。じゃ何でこんな周りくどいことしないと行けないかというと、電気的実装技術もあるんですが、下位互換性のためなんです。新しいゲーム機で古いカセットを入れられないのは当たり前ですが、いまだにPC-DOSが当たり前に動くっていうのはとても不思議なくらい下位互換性のある作りなんです。
      https://tech-blog.cloud-config.jp/2019-06-21-legacy-system-problem/
       間違えを恐れずに言うと、伝統的なつまりレガシーなということで、いまでも下位互換性を持ったシステムは現役なのです。(上のWebの例では悪い例として挙げていますが、そうやって世の中が回ってるんです。新しくするので、銀行がお休みというわけにはいきませんし、新しいシステムに移行したらいいけど、新しいゆえのバグがあったからって、預金データは壊れては困るのでやっぱり古いデータは残して読めないといけません。)
       というわけで(かなり端折りますが)、まだATX規格がありIntelはまだ今のデバイスとバスの縛りから降りられないのです。(それは、日常を守るという意味で、責任があるし、そうしないとみんなが困るからなのです。)
       責任が無いとまで言いません。でも、ゲーム機などのその他メーカーは、垂直展開なので(賭けをしてもなお)新しいアーキテクチャに進めるのです。(言いすぎだったらすいません)

  8. ありがとうございます。昔の知識を元に、MMIOなんてハードウェアで作られているから仮想化なんてできないと解釈していたのですが、大体合ってたような気がしました。

  9. ありがとうございます。はい、昔の80系はメモリー空間用とは別のアドレス線が用意されたポートマップドIOでしたね。それで68系がMMIO。

    今のPCIeはある程度柔軟にIOの番地割り当てできるように工夫されているけど、普通のメモリーが配置されている空間ほど均一ではなくて色々制約があって、効果のある仮想化はできなくて、それでDevirtualizeMMIO=trueにしても問題ないということかなと思いました。

  10. おつかれさまです。
    それでいいと思います。
    ○仮想化MMIOはプログラムと違って、スワップはできないし、リアロケーションもほとんど全くといいほど使えないし使われてないのにのに、仮想化する分MMIOはメモリを食っているので、仮想化をやめてそれを使えるようにしてる。
    ○一部、AMDでは、仮想化しておかないと動かないものがあるのでWhite Listで残せるようにしたということです。

     80系、68系懐かしいですね。私もはんだ付けで、いわゆるマイコンを作って、CP/Mをブーストラップしたもんでした。(自分でアセンブリでBIOS書くのっていい経験になりました。)
    ちなみに 
     OsxAptioFix2Drv-free2000.efiが危なかったというのは、BIOSやOSがやってるPCI周りのメモリ割当を無理やりな方法で動かしてたからなのかもしれませんねぇ・・・イニシエータでしたっけ?PCIの割り当て色々決めるのも含めて力技を掛けたんじゃないかなと想像できますね。デバイスにとっては起動時にあるだけの負荷を無理やりかけてたので、壊れるかもと危惧したのかもしれません。

  11. ガイドでは DevirtualiseMmio フラグはいつの間にか false 設定にされていますね。
    NVRAM が無い機種用の NVRAM 確保領域の設定だと思うのですが、実際にNVRAM が無い機種で
    (HP8100CMT i7-870)設定を変えてみても何の変化も無いです。
    0.6.4 用のガイド待ちですかね?

  12. 本当ですね。マニュアルではデフォルトがfalseと書いてありますね。起動に問題なければfalse推奨ということかもです。

    Dortaniaさんのガイドでは、Kaby Lake以前ではfalse, Coffee LakeとComet Lakeではtrueってなってました。手元のCoffee Lake-Sで試したらfalseでも起動したので、しばらくこれで使ってみます。

  13. お返事ありがとうございます。
     なかなか使う機能でもなく、White ListにいたってはAMDユーザ以外にはほぼ意味がないと思います。
     また、上に書かれたとおりの機能なので、NVRAMがある・なしに関わらす、trueでもfalseでも、変わりはないと思います。(試していただいてありがとうございます。)
     カーネルロード(カーネル(MacOSの肝の部分)のメモリへの配置)への問題なので、メモリマップ(主記憶域の使用状況)によって、起動の早期の段階でカーネルパニックになります。これは、主にマザーボードとそれにつけたデバイスによって起こります。
     私も、マスターのBootMacOSさんも、マニュアルとガイドを読んでみて分かりづらかったので、Insanely Macのフォーラムに行って、OpenCoreの開発者のDownload_Friz氏に聞いてきたものです。その答えが以上で投稿してあある英文になります。
     すみません。ガイドやマニュアルにはきっとこれ以上のことはかかれないでしょう。内部事情を知っても使いかたは変わらないからです。
     DeVirtualizeMMIOの意味については、専門的なことが多く、皆さんに理解してもらうためには、もっと書き方に工夫がいると思っています。ですから、どこがどのようにわからないか、教えてくれると、とても助かります。
     よろしくおねがいします。
     (どうか誤解しないでください。お試しいただいてありがたいと思うのですがNVRAMの問題ではないことだけは理解していただいた上で、わかりにくさについて率直な意見を聞ければうれしいと思います。どうかお願いします。)

  14. USB インストール時にロードメモリ量を減らす手段の1つと思っていますので、true/false どっちにすれば良いかだけでも分かれば十分な情報ですねw

  15. いただいた情報をもとに、記事の内容を補足しておきました。

  16. Asuralさん、お返事ありがとうございます。
    まず、率直に返事をくれた勇気に感謝します。あなたのおかげで、我々がどこから話せばいいか、見えてきます。
     なかなか、解りやすくするのは難しいですが、ヒントをいただけました。
     ここでいうデバイスとは、USBもそうですが、「パソコンの「中」にある機器にもデバイスと呼ばれるものがあります。たとえばCPU、メインメモリ、グラフィックメモリ(VRAM)、CD・DVD・Blu-ray DISCへの読み書きに用いるディスクドライブなど」も入ります。
    https://enjoy.sso.biglobe.ne.jp/archives/device/
     見える形で感じるところは、Windowsのデバイスマネージャーです。
    https://mifmif.mydns.jp/pcpc/public/bootmac/device.png
     誤解を恐れずに言うと、この画像にある、全部がデバイスです。
     そして、そのデバイスの根元がCPUに、メモリとして見える部分ということです。USBであれば大本としてつながっているのはほとんどの場合チップセットのホストコントローラーです。
    https://mifmif.mydns.jp/pcpc/public/bootmac/device.png
    上の画像で言うところの、Intel(R)USB3.1eXtensive Host Controller-1.10(Microsoft)がそれです。
     メモリはDDRなどの記憶装置ですが、それと同じ命令で読み書きできる「デバイスのCPUに見える部分」=IOが、つまりMMIO、メモリマップドIOです。
     同じIntel(R)USB3.1eXtensive Host Controller-1.10(Microsoft)のプロパティを見てみましょう。
    https://mifmif.mydns.jp/pcpc/public/bootmac/device-map.png
     リソースの種類にメモリの範囲と書いてあり、横に長い16進数があります。この長い16進数がメモリのアドレス(読み書きできる住所)で、ここにCPUからアクセスできるということです。
     つぎにバーチャルメモリ、仮想メモリとその動作について、誤解を恐れないで(広義の仮想化について)簡単に書きます。
     仮想化は歴史的に言うと、みんなが物理(本物のDDRとかの)メモリを使いたいけど、物理メモリは高くて少量しか使えないので、仮想的(絵空事で)に広大なメモリ地図をみんなには見せておいて、実際にはメモリに置く置き方等や、いらない部分はディスクにいったん退避してもらって、みんなで大きなメモリ地図を自由に使おうということから始まります。
     基本的に以下の方法でメモリに置く部分を小さくします。
     1.(プログラムの)リアロケーション・・・再配置可能。プログラムが物理メモリのどこに置かれても仮想メモリ上で同じ場所として見えていいなければなりません。物理メモリ上のどこにおいてもいいので、次のコンパクション(メモリの掃除)ができるようになり、物理メモリを有効に使えます。
     2.コンパクション(メモリマップ上でのリアロケーション)・・・1のように置き方がどこでも良くなるので、プログラムをたくさんいろいろ起動した後に、そのプログラムが役割を終えると、そこが物理メモリの再利用可能部分になります。しかし、飛び飛びになったメモリ領域は、まとまったプログラムの大きさでは使えないことが多いです。そこで、プログラムがどこにおいてもいいという性質を使って、物理メモリ上に、きっちり詰め替えるのです。(HDDで言うデフラグメントと同じです。空き(利用できる)領域がフラグメントする(断片化する)のでコンパクションをして領域を確保するのです)
     3.スワップ・・・置換。何らかのアルゴリズム(計算の手順・やり方)で、あまり使わない(実行しない)プログラムの一部分を、より遅くて安い記憶装置(例えばHDD等)に記憶させてしまい。もっと頻繁に動く部分のプログラムを残しておくこと。あまり実行しない部分はよけて置けるので、今今実行しないといけないプログラムの部分を物理メモリに残します。頻繁でないところを後になって使うときには、単純に言えば実行するときにHDD等から取り出して、実行すればいい。
     4.リエントラント・・・再入可能、同じプログラムを動かすときに、同じプログラムを物理メモリにおいて効率的でしょうか?プログラムの作り方として、1つの物理メモリに置いておいて、実行をもう一度してもデーターがこんがらがらないようになっていれば、同じプログラムは1つだけ物理メモリに置けばいいのです。
    (2と4は、ちょっと仮想化から外れメモリ管理やプロセス管理だと思いますが、仮想化されているため、さらにこういう方法で物理メモリを効率よく利用しているということです。)
     こうやって、高いメモリをみんなで有効に使いましょうというのが、メモリの仮想化です。
     これは、ミニコンをみんなで使う時代の頃始まったことです。今は受け継がれ、1人の人がたくさんのプログラムを動かすときにこの考え方が利用できるので、これを使っているのです。注目すべきは、仮想化というとメモリが足りないからSWAPを作ることと一般に言われてしまっていることです。メモリ管理という面で見ると、仮想メモリ技術の仮想化はリアロケーションを前提にしているのです。
     さて、そこで、ようやく仮想MMIOです。
    ○仮想化MMIOはプログラムと違って、スワップはできないし、リアロケーションからできるコンパクションもほとんど全くといいほど使えないし使われてない。そのために仮想化する分(仮想化管理用に)MMIOはメモリを食っているので、仮想化をやめてそれを使えるようにしてる。
    ○一部、AMDでは、仮想化しておかないと動かないものがあるのでWhite Listで残せるようにしたということです。
     自分でも間違えがありました、リアロケーションとコンパクションは、意識して使わけないと、いけません。失礼しました。
     

     

  17. Asuralさん、お返事ありがとうございます。
    まず、率直に返事をくれた勇気に感謝します。あなたのおかげで、我々がどこから話せばいいか、見えてきます。
     なかなか、解りやすくするのは難しいですが、ヒントをいただけました。
     ここでいうデバイスとは、USBもそうですが、「パソコンの「中」にある機器にもデバイスと呼ばれるものがあります。たとえばCPU、メインメモリ、グラフィックメモリ(VRAM)、CD・DVD・Blu-ray DISCへの読み書きに用いるディスクドライブなど」も入ります。
    https://enjoy.sso.biglobe.ne.jp/archives/device/
     見える形で感じるところは、Windowsのデバイスマネージャーです。
    https://mifmif.mydns.jp/pcpc/public/bootmac/device.png
     誤解を恐れずに言うと、この画像にある、全部がデバイスです。
     そして、そのデバイスの根元がCPUに、メモリとして見える部分ということです。USBであれば大本としてつながっているのはほとんどの場合チップセットのホストコントローラーです。
    https://mifmif.mydns.jp/pcpc/public/bootmac/device.png
    上の画像で言うところの、Intel(R)USB3.1eXtensive Host Controller-1.10(Microsoft)がそれです。
     メモリはDDRなどの記憶装置ですが、それと同じ命令で読み書きできる「デバイスのCPUに見える部分」=IOが、つまりMMIO、メモリマップドIOです。
     同じIntel(R)USB3.1eXtensive Host Controller-1.10(Microsoft)のプロパティを見てみましょう。
    https://mifmif.mydns.jp/pcpc/public/bootmac/device-map.png
     リソースの種類にメモリの範囲と書いてあり、横に長い16進数があります。この長い16進数がメモリのアドレス(読み書きできる住所)で、ここにCPUからアクセスできるということです。

  18. Bootmacさんすいません。
    投稿が見切れてしまいました。
    できれば整形してくれると嬉しいです。
    すいません。

  19. Asuralさん、お返事ありがとうございます。
    まず、率直に返事をくれた勇気に感謝します。あなたのおかげで、我々がどこから話せばいいか、見えてきます。
     なかなか、解りやすくするのは難しいですが、ヒントをいただけました。
     ここでいうデバイスとは、USBもそうですが、「パソコンの「中」にある機器にもデバイスと呼ばれるものがあります。たとえばCPU、メインメモリ、グラフィックメモリ(VRAM)、CD・DVD・Blu-ray DISCへの読み書きに用いるディスクドライブなど」も入ります。
    https://enjoy.sso.biglobe.ne.jp/archives/device/
     見える形で感じるところは、Windowsのデバイスマネージャーです。
    https://mifmif.mydns.jp/pcpc/public/bootmac/device.png
     誤解を恐れずに言うと、この画像にある、全部がデバイスです。
     そして、そのデバイスの根元がCPUに、メモリとして見える部分ということです。USBであれば大本としてつながっているのはほとんどの場合チップセットのホストコントローラーです。
    https://mifmif.mydns.jp/pcpc/public/bootmac/device.png
    上の画像で言うところの、Intel(R)USB3.1eXtensive Host Controller-1.10(Microsoft)がそれです。

  20.  メモリはDDRなどの記憶装置ですが、それと同じ命令で読み書きできる「デバイスのCPUに見える部分」=IOが、つまりMMIO、メモリマップドIOです。
     同じIntel(R)USB3.1eXtensive Host Controller-1.10(Microsoft)のプロパティを見てみましょう。
    https://mifmif.mydns.jp/pcpc/public/bootmac/device-map.png
     リソースの種類にメモリの範囲と書いてあり、横に長い16進数があります。この長い16進数がメモリのアドレス(読み書きできる住所)で、ここにCPUからアクセスできるということです。

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

  22.  基本的に以下の方法でメモリに置く部分を小さくします。
     1.(プログラムの)リアロケーション・・・再配置可能。プログラムが物理メモリのどこに置かれても仮想メモリ上で同じ場所として見えていいなければなりません。物理メモリ上のどこにおいてもいいので、次のコンパクション(メモリの掃除)ができるようになり、物理メモリを有効に使えます。
     2.コンパクション(メモリマップ上でのリアロケーション)・・・1のように置き方がどこでも良くなるので、プログラムをたくさんいろいろ起動した後に、そのプログラムが役割を終えると、そこが物理メモリの再利用可能部分になります。しかし、飛び飛びになったメモリ領域は、まとまったプログラムの大きさでは使えないことが多いです。そこで、プログラムがどこにおいてもいいという性質を使って、物理メモリ上に、きっちり詰め替えるのです。(HDDで言うデフラグメントと同じです。空き(利用できる)領域がフラグメントする(断片化する)のでコンパクションをして領域を確保するのです)

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

  24.  こうやって、高いメモリをみんなで有効に使いましょうというのが、メモリの仮想化です。
     これは、ミニコンをみんなで使う時代の頃始まったことです。今は受け継がれ、1人の人がたくさんのプログラムを動かすときにこの考え方が利用できるので、これを使っているのです。注目すべきは、仮想化というとメモリが足りないからSWAPを作ることと一般に言われてしまっていることです。メモリ管理という面で見ると、仮想メモリ技術の仮想化はリアロケーションを前提にしているのです。

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

  26. BootMacOSさん、直していただいてありごとうございます。
    話が、うまく伝わらずすいません。
     Swapできないのは当然ですが、コンパクションが困難でだれも行わないので、コンパクションの条件であるリアロケーションという仮想化を切る(デバーチャライゼーション)というのが正解だと思います。
     よろしくお願いします。

  27. 「DevirtualiseMmio = True が正解で、起動しない場合には False に設定してWhite Listの定義が必要」
    と云う理解で正しいですか?

    False 設定の対象としては AMD CPU だけでは無く Intel の Sandy bridge 以前の CPU も含まれる為に
    具体的にWhite Listの設定をどうするべきかについて個々に議論が必要になるかと思います。
    HP8100CMT についてはUSBインストールが出来ない状態の為に「状況に変化なし」としました。

    1. 元の記事を読んだ感じでは、デフォルトがfalseなので、基本的にはfalseが正解だと思います。DortaniaさんのガイドによるとKaby Lake以前のCPUはfalseで良いようです。それで起動しない場合は、trueにするのだと思います。同ガイドでは、Coffee Lake以降のCPUはtrueが良いと書いてありますが、手元のCoffee Lake-Sではfalseでもokでした。AMD Threadripper TRX40 19H などの一部のシステムの場合は、trueにすると、さらにwhite listの設定が必要という意味のことが書いてあったと思います。

      メモリー確保に失敗したという内容のエラーで起動直後にすぐに止まってしまう症状以外でしたら、この項目は関係ないと思います。

      1. >メモリー確保に失敗したという内容のエラーで起動直後にすぐに止まってしまう症状以外で>したら、この項目は関係ないと思います。

        了解しました。
        結局「侵入禁止」表示には無関係の様ですね。

        1. メモリー確保失敗も「侵入禁止」マークになりますので関係あります。OpenCore/Cloverのブート選択メニュー画面のすぐ後に出るようでしたら、メモリー確保失敗の可能性があります。「侵入禁止」が、具体的にどのエラーなのかは-vでチェックすると良いです。

          1. あ、申し訳ありません
            実際に False 設定でないと動作しないCPUが在るのですから、関係がありますね。私にとって関係が無さそうなだけでした。
            ご教示ありがとう御座います。

  28. 遅くまでおつかれさまです。
     すいませんでした。
     リアロケーションというと再割り当てになるので、コンパクションと意味が同じですね。
     正しくはリロケーション、リロケータブルです、
    http://www.hino.meisei-u.ac.jp/is/iga/lecture/os/No5note.pdf
     広くメモリ管理として、理解されるところのようですが、ここでは、仮想化の1つとして捉えられているようです。

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

  30. *「DortaniaさんのガイドによるとKaby Lake以前のCPUはfalse(Defualt値)で良いようです。」に関して

    参考:拝読して興味が湧いたので、手元のDesktop : ( 6th Gen ) SkyLake機器でtrueにしてみました。
    – ブート開始の最初のステップ(処理状況を示すバー)の最初の突端でストップ。
    – バックアップドライブのEFIに切り替えて再起動、元の値:falseに復旧して落着。学習効果あり。
     

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

  32. もう一度、再トライです。
    A.仮想記憶
     1.スワッピング・・・置換。何らかのアルゴリズム(計算の手順・やり方)で、あまり使わない(実行しない)プログラムの一部分を、より遅くて安い記憶装置(例えばHDD等)に記憶させてしまい。もっと頻繁に動く部分のプログラムを残しておくこと。あまり実行しない部分はよけて置けるので、今今実行しないといけないプログラムの部分を物理メモリに残します。頻繁でないところを後になって使うときには、単純に言えば実行するときにHDD等から取り出して、実行すればいいのです。

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

  34. B.メモリ管理
     1.リロケータブル・・・再配置可能。プログラムは物理メモリ主のどの領域に配置しても実行できるようにします。(そもそも、プログラムをそうできるように作っておくか、(起動でもスワップでも)読み込み時に、プログラム内のアドレスを書き換えて読み込めば、どこにおいても良くなります)

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

  36.  3.コンパクション(メモリマップ上でのリアロケーション(再配置))・・・
     プログラムをたくさんいろいろ起動した後に、そのプログラムが役割を終えると、そこがいらなくなります。そしてそこが物理メモリの再利用可能部分(空きメモリ)になります。このようにやってくと、飛び飛びになった空きメモリ領域は小さくなってて、まとまったプログラムの大きさでは使えないことが多くなりがちです。

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

  38.  そして、仮想記憶のアドレス変換がありしたから、仮想記憶のアドレスを、物理メモリのアドレスに変換できます。
     コンパクションを行って物理メモリないのプログラムの位置に変更があっても、仮想メモリでは、相互のアドレスを変換するところ(実際は表(テーブル)のです)をいじくっておけば、前と同じ仮想メモリのプログラムの位置(仮想アドレス)で、物理メモリのプログラムの位置(アドレス)を実行できるので、実行プログラムの管理(プロセス管理)がうまくいきます

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

  40. ええーっと、だいぶ私にも勉強になりましたね。
    さいごに戻ります。
    ○仮想化MMIOはプログラムと違って、スワップはできないし、コンパクション(メモリマップ上でのリアロケーション(再配置)・・・これがFrizとのメッセージの意味です)もほとんど全くといいほど使えないし使われてない。そのために(コンパクションができるようになる)仮想化する分(仮想化管理用に)MMIOはメモリを食っているので、仮想化をやめてそれを使えるようにしてる。
    ○一部、AMDでは、仮想化しておかないと動かないものがあるのでWhite Listで残せるようにしたということです。

     勉強になりました、おかしい所、わかりにくい所があれば教えて下さい。

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

  42. 夢日記を読ませていただきました。わかりやすく解説していただいてありがとうございます。ただ、最後の方の、コンパクションが困難なので仮想記憶をoffにするというところが少し理解できませんでした。物理メモリ領域が物理的に飛び飛びに配置されていても、論理アドレスで一見連続に見えるようにマッピングしてくれれば、コンパクションしなくても断片を跨いで実行できるのではと思いました。

    MMIOの部分は、実アドレス=論理アドレスじゃないとダメという制約がもしあるなら、(PCIeの割り当て番地をコントローラチップに聞いて、そのアドレスに直接アクセスしてくるドライバーなどありそうですから)、論理アドレスでも断片化が発生してしまうので、仮想化しても解決できないので、それで止めておく(de-virtualiseする)、という意味なのかと思ったのですが、いかがでしょうか。論理アドレス空間が広大なら、断片化してない空き地がいくらでもできるけど、ブートの時のメモリー空間は限られているのではとも思います。

    1. 御返事ありがとうです。
       仮想メモリマップで、フラグメントした物理メモリの空き領域をマッピングして、利用することはできると思います。OSでも(積極的にというか自動ではしないとおもいますが)事実上やってると思います。少なくともプログラム自体は断片化しなくても。プログラムが大量のデータ領域を取得したい場合があれば、離れたページを利用するので、断片化します。でも以下のように、あまり(というかきっと積極的には)プログラム自体を断片化しないでしょう。
      https://itmanabi.com/memory-compaction-gc/
      それは、プログラム自体は(仮想メモリでなく)物理メモリに配置されるので、断片化することに手間がかかるからだと思います。やろうと思えば出来なくもありません。
       例えば単純なループ構造を持ったプログラムで、ループの中身が断片化したとしましょう、CPUが見てるのはあくまでも物理メモリです、ですからループを起こすアドレスの飛び先を変えるのと、断片化した部分を通り越して起こる(割り込み)信号を検知して仮想化テーブルを見てプログラム(読み込みのアドレス)カウンタを飛ばすことをしないといけません。ソフト的にはこのようにしますが、ハード的に実装すれば、自動的に一覧表で処理できるかとも思いますが、メモリ転送技術やキャッシュ・パイプラインといった高速化技術はプログラムが断片化なくまっすぐ進むことを仮定としていますので時間的オーバーヘッドがばかにならないからでしょう。(逆にコンパクションが必要な理由はそこにあるんだと思います。)
       きっとメモリが一番問題でしょう、DDRは1〜5くらいまでありますが、その数が進んでいく理由は以下のようなものです。
       メモリチップ自体が網の目に並んでいて、1つの行にたくさんのデータが乗っているので、一回のアドレスを電気的に指定した場合に、+1,+2・・・していくアドレスのデータをアドレスの電気的な指定なく、クロック信号の上下だけで、次のまた次のアドレスの順番にデーターを出してくれます。その順次データーを出す個数が上がっていくのでDDR1〜5とか言うんです。
       ランダムアクセスメモリなので、完全にランダムに出せるというのは本当ですが、メモリのセル(ビットの蓄積場所)が、網の目に並ぶ以外にないため(SF的かもしれませんがトポロジー的に優位な方法がありえないとまで言えないとは思いますが)、途中で分断して読み込むのは、網の目の別の行に移ることになるので、物理的に遅いのはどうしようもありません。
       このようにプログラムが分断するのは、とても時間的コストがかかり、時間的オーバーヘッドが大きいので、コンパクションをして、(できるだけかもしれませんが)分断しないようにプログラムを読み込んでいるのです。

      1. 失礼しました。一度アドレスを指定して、連続読み出しをすることをバーストといいますが、DDR2で4ワード、DDR3で8ワードになっただけでした。
        あとは、高クロック化などで転送速度を出しています。
        https://www.architek.ai/old/design/ex_ddr1.html

    2. ごめんなさい、仮定のことになるともう好みの問題でしかなくなるのですが・・・
      「MMIOの部分は、実アドレス=論理アドレスじゃないとダメという制約がもしあるなら」
      というのは、採用しかねます。
      なぜなら、すでに仮想化MMIOと言っているからです。
      そして、Frizも誰もそうしないと言ってるだけで、出来ないとはいっていません。
      きっとイニシエーション時にデバイスはコントローラーに向かって、アドレスのどこがほしいか、言ってくるとおもいます。ですから、出来ないと言いたいところはわかりますが・・・

      1. お疲れ様です
         これは予想でしかないのですが、Windowsの各種メモリマップで、メモリ量が積載したRAMの分でないって報告があるようです。
        https://support.microsoft.com/ja-jp/help/929605/the-system-memory-that-is-reported-in-the-system-information-dialog-bo
         実際にMMIOが仮想メモリマップとして見えているから、利用者側から見た結果でも、そうなるんだと思います。
         新しいチップ(MMU=メモリマネジメントユニット)では、この4GB以内にあるMMIOの裏にある、物理メモリ(V-RAMの用に実際に使われている部分を除いて)の隠れてしまうところをひろって、仮想メモリに足している(いわゆるバーチャライズしてるんだと思います。
         ただ、メインメモリをV-RAMに使うとこれは実際にメインメモリを使わないといけないので、仮想化して裏にある物理メモリはないので仮想化メモリマップに載ってくるので、OSがプログラムに利用できる部分が少なくなるのだと思います。(ただ、絶対にプログラムがMMIOを仮想からしかアクセスできないのではない=物理メモリをアクセスする方法があるので、必ずしもUHDなどを使ってもWhitelistがいらないのだと思います)

    3. おつかれさまです。
       もう一度、東大の講義資料を読んでましたが、そもそもが、プロセスごとに、連続な空きがあって(作って)いれる用に書いてありますねぇ・・・
       コンパクションがいらないっていうのは、素朴な疑問だと思いますが、答えるのはなかなか難しいですねぇ
       悩ましいですねぇ・・・

  43. あとは以上のことを踏まえてどのように、文章なおしたり、保管したらいいか考えなければなりません。

    なにかいい案はありませんか?
    意外と文章は苦手なんですよね・・・(ノД`)

    1. 不明点などがまだあれば、ここで答えますので、ちょっと時間がかかるかもしれませんが、忌憚なく質問してください。(わからない場合はすいません)

    2. お疲れ様です。
      連続領域が必要なのは、
      https://ednjapan.com/edn/articles/0807/01/news154.html
      で、今使ってるDDRが、一番問題あるとみて、Q&Aで組み立ててみました。
      さらに、少し混んで書いてあってわかりにくかった仮想MMIOの最後の下りをほぐしてみました。
      まぁ、草稿1ですかね^^;
      なんか、大学のレポート作ってるみたいですが・・・ここまで書いてあるのは、日本しかないでしょうねぇ^^ww

  44.  すいませんが違うんです。ごめんなさい。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.

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

  45. お疲れ様です。
    お忙しい中すみません。
    こっちの文面で、最後のMMIOのくだりを変えて見てます。
    どうでしょうか。
    急がせるつもりではありませんが、理解できない所を、フランクに言ってくれたら助かります。
    よろしくお願いいたします。

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

  47. BootMacOs様
    私の勘違いだといいのですが、大変申し訳ありません。
    お返事が得られないので、無視されているのだと思います。
    表現や問題の採用方法に、問題があったことを率直に謝罪します。申し訳ありませんでした。
    これからの、提案につき、そのままAlphaのページにを載せますので、どうかお許しください。
    大変、申し訳ありませんでした。

    1. alphaさん、そんなことは全くないです。説明していただけたことを反映して、「仮想化しても断片化が解消されない」ことを本文に追記してあります。わかりにくくてすみません。今後も引き続き、有意義なコメントをいただければ助かります。よろしくお願いします。

      1. お忙しい中、お返事ありがとうございます。。
        勘違いしてすみませんでした。
        これからもよろしくお願いいたします。

        (MMIO cannot be relocated with just virtualisation, so no, it does not make anything more difficult, and afaik nobody does this anyway)
        (MMIOは仮想化だけでは再配置(この場合コンパクションのことですからこれでいいのですね)できないため、いいえ、それ以上の困難はありません。とにかく誰もこれを行いません)

        ありがとうございます。

  48. ご理解いただいてありがとうございます。
    細かくて申し訳ないのですが。コンパクションは、HDDがいりません。
    そのため、「仮想化の仕組みで<退避させて>その場所が空けば」と書いてしまうと、HDDに<退避>しないとコンパクションができないように聞こえてしまうので。
    コンパクションの意味が伝わっていないと考えてしまったのです。

    大変申し訳ありませんでした。

     以下に例をあげましたが、①HDDの退避が、MMIOなので、事実上意味ない(というか、アドレスを占有し続けるので、データと違ってできないという方がいいのかもしれません)という部分。
     ②そのほかに、メモリ管理で、仮想化されているために実際のアドレスをコンパクション(デフラグを解消する=詰める)して利用することが期待できるが、MMIOでは仮想化だけでは、それもできないという部分
     そして、仮想化に、MMIOがメモリ領域を使っているので、無駄なのでそれを開けてカーネルに開放する。
    の3段が必要だと思います。(細かくて申し訳ありません。)

    元)
    「ただ、MMIOの部分は、メモリーではなくてIOデバイスだったりするので、HDDに退避してもその番地が空くわけではないです。仮想化の仕組みで<退避させて>その場所が空けば、メモリの断片化も解消できるのですが、それができません。なので、MMIOの部分では仮想化のメリットはないです。でも仮想化のために、ある程度の作業エリアが必要になります。DevirtualiseMMIOは、MMIO部分を仮想化しないよう設定して、作業エリアを作らないようにして、メモリを節約します。それでカーネルが読み込まれる領域を少しでも確保して、起動失敗を避けようというフラグです。」

    例)
    「ただ、MMIOの部分は、メモリーではなくてIOデバイスだったりするので、HDDにそこの内容を退避してもその番地にはIOデバイスがいるので、メモリが空くわけではないです。(つまりHDDに退避しても意味がありません。)
     さらに他の仮想化に由来する仕組みを利用して、メモリの場所を詰める操作で、メモリの断片化も解消できるのですが、MMIOでは仮想化の仕組みだけでは、それができません。
     なので、MMIOの部分では仮想化のメリットはないです。でも仮想化のために、ある程度の作業エリアが必要になります。DevirtualiseMMIOは、MMIO部分を仮想化しないよう設定して、作業エリアを作らないようにして、メモリを節約します。それでカーネルが読み込まれる領域を少しでも確保して、起動失敗を避けようというフラグです。(わかりやすく詳しく知りたい方は夢日記に書いてあるようです。)」

     ぐらいになるのでしょうか・・・もっとうまい言い方があるといいのですが、できれは、うまくまとめていただくと、うれしいです。
     よろしくお願いいたします。

  49. そうですか、本当に申し訳ありませんでした。どうか許してください。ごめんなさい。
     開発者のFrizにまで聞いて、できる限り(BIOSがデバイスのメモリマップを決めた所の)を答えを出したのですがとても悲しいことです。ほんとうにごめんなさい。
     まず、Linuxのこの説明は、「BIOSがメモリを無視して、MMIOが取られるので、そこをメモリホールといい、全部使えないので、最終的に64ビットOSでは仮想アドレスへのマッピングが行われることが多く、Fedora 8(x86_64) ではこの対策としてLinuxカーネルが物理メモリを仮想アドレスにマッピングされ0.7GB ほど上位の仮想アドレスにマッピングし直され、結局メモリを多く使える」と言っているものです。BIOSの段階でMMIOを仮想化しなくして、カーネル読み込みメモリをかせぐというものでは<ない>のではありませんか。(私の解釈です。)

     BIOSでのMMIOの取得のあとに、Fedora 8(x86_64) を含む各OS(BSD系であるMACOSもそうしないはずがありません)最終的に64ビットの仮想アドレスを使うとともに、MMIOも再イニシエーション(仮想化でない再配置を)して、置きなおしメモリホールを作らないように動いているはずです。

     ここでの、デバーチャライズは、BIOS下でしか意味を持っていないことに注意してほしいと思います。MacOSのそれを制限してはいません。(だからmemmapが4GB分しか結果が出ないのだと思います)過去との整合性を取るために、BIOSは4GBで動く必要があり、初期カーネルを読み込む領域もいまだにそれにならっているのです。
     ですから、問題はメモリホールではないのです。<BIOSが>過去との互換性のある方法で配置したMMIOが、仮想化可能にしていると、<BIOSの>MMIOの配置でメモリを多く使うので、非仮想化(デバーチャライズして)して、<BIOSの>MMIO配置の時にメモリを食わなくなって、初期カーネルを置く連続した利用可能なメモリが得やすくなるのです。

  50.  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.
    @ Alpha999ここでの「仮想化」は、CPU仮想化(VT-x、VT-d)ではなく、メモリ仮想化(ページテーブルのもの)です。はい、利点の1つは、メモリを物理的に移動しても、アドレスを同じに保つことができることです。 MMIOの仮想化はほとんど意味がありません(MMIOは仮想化だけでは再配置できないため、これ以上難しいことはありません。とにかく誰もこれを行いません)。問題は、Appleがboot.efiによって移動されたかどうかに関係なく、仮想化メモリ用にメモリを予約するため、役に立たない(文字通り未使用の)仮想化MMIOスペースが初期カーネルメモリを増やすことです。

    ここでの再配置(リアロケーションとはコンパクションに他なりません。つまり、再配置して、連続した空きを作って、初期カーネルを置くのですから)

    ○仮想化MMIOはプログラムと違って、スワップはできない(メモリの記録でなく機器・装置の入出力を行う部分だからHDD等に持っていくということ自体出来ません)し、コンパクション(メモリマップ上でのリアロケーション(再配置)=これがFrizとの英語のメッセージの意味です)もほとんど全くといいほど難しくて使えないし使われてない。その仮想化をするのに仮想化MMIOはメモリを食っているので、仮想化をやめてそれを使えるようにしてる。そして、連続した領域がカーネル読み込みに使えれば目的達成ということです。

    どうかご理解いただけれは、幸いと存じ上げます。
    お願いいたします。

  51. 私が、質問した内容も、参考として置いておきます。
    Hello,everyone.

    I’m Alpha (on behalf of Mifjpn).
    If you have a time,may I ask you a little?
    Please educate me, who is ignorant.

    About Devirtualise Mmio. According to the OpenCore manual.
    “Remove runtime attribute from select MMIO regions.
    This option reduces stolen memory footprint from the memory map by removing runtime bit for known memory
    regions. ”

    I don’t really understand this “runtime attribute, runtime bit”.
    I looked them up, but they didn’t appear in the search, or some pages I didn’t understand.

    With virtualization, programs can be executed without deciding where to place physical memory. And I think it can be relocated on physical memory.

    I found out by investigating that MMIO is also virtualized with VT-d technology. If so, I think that the part other than the available area that can be seen in memmap in the UEFI shell (I think this is physical memory because the kernel is not running yet) is MMIO (resource).
    If they are virtualized, can they be moved (relocated) in physical memory?

    I’m not sure about this. Maybe I’m misunderstanding.

    Setting “Devirtualise Mmio” to True means to stop MMIO virtualization.
    In other words, the location in the physical memory is decided (by the absolute value address). If so, I think that you will directly operate the physical memory without taking the virtualized access method, I’m sorry, this idea may be wrong anymore.

    If so, you can’t relocate because you can’t virtualize it, so on the contrary, I think it’s even more difficult to choose the physical memory to put the Kernel, but what do you think? I’m confused around here.

    On the contrary, if MMIO is devirtualized, does it mean that the firmware will relocate it outside the area where it cannot be virtualized (relocated) (for example, outside the 4GB area where there is a problem with PAE)?

    I would be happy if you could teach me.

    Thank you

    PS

    There is a forum master in a Japanese forum that summarizes the task of choosing a Slide value from a memory map, where KASLR is the problem if you panic early in the kernel boot. (Needed on some motherboards)

    He didn’t understand the implications of MMIO devirtualization, but he did understand the Dortania settings. So by setting Devirtualize to True, I knew that I didn’t have to set Slide. (The method recommended by OC is not to set Slide, that is, I think that it is also basic in the current Clover)

    So, if I knew it even a little, I thought it might be useful for future CPUs and chipsets (especially AMD).

    In fact, HELP at AMD is coming to his Japanese forum. It doesn’t work well even with OpenCore. Since iCanaro is familiar with MMIO, I can only tell them that the Clover Quirks he wrote was on the Italian version of OSx86.

    I thought it would be nice if I had a little more understanding.

    I don’t really like taking everyone’s time, but curiosity may help for the future, so I’d like to post a post in the discussion asking you to tell me about MMIO relationships if you have the time.

    What I learned here is to have the Japanese Forum Master publish it.
    At the very least, Japanese [Hakin | Razen] tosher will be used with an understanding of what is taught here.

    (It would be great if Japanese people who are workaholics understand that even their hobbies are a little addictive.)

    Thank you.

  52. 今まで積み上げてきたものを、無視するようなことは、どうか、どうか、しないでください。本当にお願いいたします。
    私が、文献を探して調べ上げた時間は、私が好きでやっていることですから、無視しても構いません。
    でも、Astralさんが間違えも恐れずに、勇気をもって、投稿したことは、忘れないでください。
    どうか、どうか、お願いいたします。

  53. お疲れ様です。
    対応につかれました。
     BootmacOs様が情報が欲しいということで、Clover DiscussionにOpenCoreのDeveloperのFrizまで呼んで、聞き込んだのです。
     情報について、Astralさんが勇気をもって投稿してくれ、かみ砕くべく、東大のOSの講義の資料を基にまでして、取り組んだというのに、それをパージして、独自解釈を別の参考から求められることが、果たして、情報が欲しいと言っていたこととどのようにそぐわないかを、もしよろしければ考えていただけないでしょうか?
     どうか、中道を取ったかの如く見える方法を取らないで、ご誠実に、私のおかしい点についても、指摘していただければと思います。
     道徳性のある、よりよい人生を送られますように、お言葉をささげさせてもらいます。
     ありがとうございました。

  54. 再度私の間違えだといいのですが、やっぱり無視してるんですね。
    そして、人の苦労を無に帰すことに何の痛痒も感じないのですね。
    がっかりです。

  55. 色々ご指摘ありがとうございます。OpenCoreのソースコードを見たところ、安易な想像で書いていたと思ったので、シンプルに書き直しておきました。

  56. 大変申し訳ありません。
    BootmacOs様が情報が欲しいということで、すべては始まっているのです。
     Astralさんも勇気をもって投稿してくれたのです。
     果たして、Developerたちは、好き好んでいるから、無償でIssueを直してくれているのでしょうか?Frizは時間を割いてまで、なぜ動作にかかわりのない理由についてまで、解説してくれたのでしょう。
     なぜ、OpenCoreで我々に恩恵を与えてくれるFrizの好意を、ごく単純に受けられないのですか?これほど寛大なフォーラムを持っていらっしゃるのに、不思議でなりません。私の解釈が嫌なら、Frizの文面そのままを張ればいいだけではありませんか?
    (何が嫌なんですか?私が関与することですか?だったら、Frizの文面を貼ればいいことではないですか?)
    すべて過去の出来事に清算をつけることが「シンプルに書き直しました」ということにされています。苦労を無に帰すことだということなので、大変申し訳ありませんが、問題を無視されていらっしゃいます。
    (ソースを読んだとおっしゃいますが、そのソースをかいたのはFrizたちなんですよ)

    1. 知識が足りなくてAlphaさんが書かれている技術的な内容が理解できていません。納得できたことだけを記事にしたいと考えています。質問したとしても、コメント欄の断片的な文字の文章では、理解できそうにないです。ヘタレですみません。せっかく調べていただいた内容なので、ここで説明を続けるのではなく、「夢日記」の方で、図やグラフや具体的なメモリーマップなどを用いて、わかりやすく書いていただければ、とても助かります。

      ログイン忘れてました、bootmacosです。

  57. ご苦労をおかけして大変申し訳ありません。
    まず、ソースコードのどこを読めば、当該デバーチャライスの操作がわかりますか?
    Cは私のネイティブなので、コードは読めますが、ライブラリがOS上にあるものではないので、ライブラリは特殊になります。そのため、おたずねしたいことがいっぱいになると思います。
    Bootmacos様が、このようにしたことが正当であると、納得の行くように、できる限り理解させていただきますし、努力し問題を解決できることを信じています。
    そのために、たくさんの質問をしなければなりません、どうかよろしくお願いいたします。

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

  59. だいじょうぶですよ!Bootmacosさん!。
    長らく付き合った仲じゃないですか。
    仕組みが知らないからって、自動車を運転しないわけではないでしょう。
    はーい、ハッカーなら調べましょう!!。仕事の休みが取れるのがいい事に、貫徹して調べ上げましたよ。
    まず、Frizにこれでいいのか聞きましょう。
     私もまだ、しらべたばかりなので、動き自体の詳細はあまり説明できません。というか、そもそも今のハードは抽象化が進んでて、UEFIで、すでに、BIOS段階でメモリ仮想化されてて、さらに、そこではx86互換のマップですが、XNUカーネルも(Frizがちょっとだけ形容詞を付けたように)初期カーネルをロードしてメモリ設定のうえ、カーネル由来の仮想化をして、特権仮想アドレスに最終カーネルができるようですから。

    以下を聞いてみましょう。

     アプリ領域はもちろんXNUカーネル由来の仮想メモリアドレス上にある。また、ハイブリッドカーネルなので、ドライバも入っているがそれ自体も仮想メモリアドレス内で動いており、IOへのアクセスは、IO Kitによりクラス化されたIOインスタンスへのアクセスとして実現している。

     初期カーネルを経て、メモリやIO等の設定の済んだXNUカーネル自身もそれ自身の仮想メモリアドレスにある(カーネルなので当然特権のあるメモリで守られている)。そして、ドライバがIOをアクセスするには、IO Kitを使う。

     しかし、カーネルロード前は、UEFIBIOSでの管理されているので、ファームウェアは、UEFI由来の仮想アドレスマップにある。そのため、PCIexのMMCONFIGがメモリマップ上にある。さらに、UEFIはそのままではIdentity Mapped Pagingモードなので、MMCONFIGの領域もRUNTIMEBITがセットされていて、仮想化されているが無駄なので非仮想化し、そのページを物理メモリとできて初期カーネルの置き場所が増える。しかし、CPU.Cipset,デバイスによっては、仮想化されたUEFI由来の仮想アドレスマップを必要とするものがあるので、Whitelistに入れて、仮想化しておく必要がある。

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

  61. お疲れ様です。
    上を踏まえて、書き直しました。
    https://mifmif.mydns.jp/alpha/?p=1006
    粗削りなので、まだ直すつもりです。
    質問があれば、向こうのコメントに入れてください。
    わかる限りなおします。
    OpenCore Discussionでは、このような話題は取り扱わないような感じですね。
    ただ、Runtime bitの件や、初めから仮想化されていること。BOOTX64.efiという名前で、x64でのefiプログラムとして動くことから言って、これ以外の解釈のしようがありません。
    ほしいと、おっしゃてた、メモリマップですが、シェルのmemmapを一応載せました。
     x64モードでリセットしたときの(BIOSすら動いていない)Mapが欲しいのなら、それも入れる用意がありますから、遠慮なく言ってください。ただ、CPUのそのもののSpecなので、完全な理解はできないです(補筆にあるように、MMIOのコンフィグレーション(設定)前であるということです)。
    よろしくお願いします。

    追伸
     あまり言いたくはないのですが、CPU自体が抽象化(文学的意味でなくて、論理的に具現化できる形の抽象という意味です)、されているので、すべての配線の理解は意味がありません。
     たとえば、ioregコマンドで見るアドレスが違うのも、配線で違うようにつながっているだけの訳ではありません。チップセットにより、UPnP(PCI関係)の番号取得アルゴリズムは違いますし、BIOSのライブラリでのMMIO割り当て方や、OSのMMIOの再設定で異なるのです。
     さらにいえば、MacのioregはC++のクラス定義された、インスタンスのカタログとしてのデータベースです。IO Kitで借りてきて、そのインスタンスに実際にはアクセスして処理するんです。
     これほど抽象化されているのに、線一本の話をすることはできません。
     ご理解がそういう配線的な意味まで必要であれば、申し訳ないのですが、自己矛盾なさっていらっしゃいます。どうか、ご容赦ください。

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

  63. お疲れさまです。
    失礼します。
    「(以下はこちらを参考にした推測です、間違っていたらすみません)」は、完全に的を外しています。
    我々は真実の探究者で、できるだけ嘘のない、Hackintoshに対する理解をしようではありませんか!?
    勇気を持って行動するのは、あなた次第です。
    私もすべての理解が及んでいるとか、納得できてるなんて、言えません。
    なぜなら、Mac-OS自体が、Closed-Sourceなんですから・・・
    話を続けて、理解しようとすることは、つまり、これから出る新しいMAC-OSに対応していくことと同じなのではないですか?
    お返事をお待ちしております。

    1. 何かストーカーみたいでキモいっすよ。

      ブログなんだから人には人の生活のペースや返信のペースもあるんですし、ネットの繋がりなんて他人じゃないですか。友達とラインやってる訳じゃないんすよ。返信強要とか何か怖いす。
      上から目線でやるなら自分の所でやればって話しですし、より深い話でやりたいなら自分で新しく場所を作ればいいじゃないですか?

      自分にはちんぷんかんぷんなお話ですが、とにかく落ち着けよって思いました。

      1. 恋愛とかの話ではないですから。。。ストカーとか言われる方の身になって言い方をお気をつけなさる方がよいかもですね?しかも、匿名で投稿するなら、尚更なんか、無理やりチャチャいれてる気もしますけどぉ。。。適当なお名前つけて、そう熱くならないでと言えば、相手も気づけかないじゃなあいかなぁとか思いましたね。

        Alpha さんは常連ですし、内容的にテクニカルな話なんで、どうしても長くなるつっうか、しょうがないんですよぉ。。。ちんぷんかんぷんわかんないならスルーするのが一番良いと思いますけどね。ただ私も完全に理解するにはちょっとむずいですけどKASLR Slideに関するの日本語の話は、たぶん、ググってもなかなか見つからないと推察されますから(bootMacさんのこのサイトぐらいじゃないかな???)、非常に貴重な内容かもしれないと思って見てますので長い目で、きっちり結論がでれば、テクニカルコンテンツとしては、素晴らしい?(BootMacさんがまとめていただく?)コンテンツかつ、ご本人自身も我々もクリアになれば良いですね!

        とにかく、擬実的な話なんで、わかんない人はスルーでお館さまがまとめていただける可能性もある?ので、静観してれば良いですよ。www。たぶん?w

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

  65. 疑心暗鬼になりました。
    素直に謝ります。
    申し訳ありませんでした。

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

返信を残す

メールアドレスが公開されることはありません。