| RFC-0252：無實體 VMO 快取運作 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 移除實體 VMO 的快取作業。 |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-06-12 |
| 審查日期 (年-月-日) | 2024-07-18 |
摘要
移除直接在實體 VMO 上執行快取作業的功能。
提振精神
實體 VMO 上的快取作業目前依賴
3ysmap由於實體 VMO 只能透過對應來操控
隨時可改用現有的 zx_cache_flush 作業。
實體 VMO 通常代表實體位址空間的非 RAM 區域 例如 MMIO 暫存器。執行快取作業在無意義的情況下 則會導致嚴重錯誤，具體情況取決於架構和硬體。雖然 必須建立受限制的資源，才能將 讓使用者停止運作核心的方法仍是件好事。
相關人員
講師：
cpu@google.com
審查者：
mcgrathr@google.com、hansens@google.com、jbauman@google.com
諮詢：
社交功能：
由 Zircon 核心/VM 團隊共同探討。
設計
zx_cache_flush 已存在且已實作，因此沒有任何新的
為這個提案量身打造因此提案只是
支援下列實體 VMO 作業 (即
zx_vmo_create_physical:
ZX_VMO_OP_CACHE_SYNCZX_VMO_OP_CACHE_INVALIDATEZX_VMO_OP_CACHE_CLEANZX_VMO_OP_CACHE_CLEAN_INVALIDATE
這些作業在非實體 VMO 上，也就是透過 zx_vmo_create 建立的
zx_vmo_create_contiguous、zx_vmo_create_child或zx_pager_create_vmo，將
維持不變並照常運作
這會導致實體 VMO 與未分頁的 VMO 之間出現不同的 API 因為程式碼可能需要容許上述兩種類型不過 因此不使用任何實體 VMO，而且會移除 VMO 目前尚不可使用 需要支援任何類型的 VMO 的程式碼 請務必確保圖示有可用的對應
實作
在樹狀結構中，實體 VMO 快取作業的用途非常多，
需要快取作業的位置已經採用偏好的設定
zx_cache_flush。以現有的 VMO 快取作業來說
可以改用 zx_cache_flush 的現有對應，以便
遷移程序
實作計畫如下：
- 遷移任何涉及實體 VMO 的現有 VMO 快取作業使用情形。
- 停用實體 VMO 的快取作業，並讓這些作業傳回
ZX_ERR_NOT_SUPPORTED。
成效
使用 zx_cache_flush 執行快取作業應比
執行系統呼叫，因此這類變更通常能帶來淨成效
唯一的例外是有地圖需求
不過，實體 VMO 並不常用，沒有這類情況
現今的產業日後如需變更，可重新評估這項決定。
人體工學
目前大多數的快取作業已改由 zx_cache_flush 執行
盡可能提高使用便利性，並採用人體工學
因此一律比 VMO 作業更理想不過
若是沒有對應的對應，則作業速度會大幅下降。
回溯相容性
這是 API 破壞性變更，但快取作業是由少許內容完成 但通常是駕駛和類似因素的使用者， 因此不應對現有程式碼進行難以遷移。
安全性考量
這個提案同時會將程式碼與邏輯從核心中移除，並造成使用者 在背景執行期間，系統不會對潛在裝置記憶體進行控制的快取作業 會在特權模式下執行因此從 安全觀點
缺點、替代方案和未知
本提案的假設是，在實體機器上使用快取作業 VMO：
- 已有對應關係，並改成對其執行快取作業，方式為 因此效能提升，而且無負面影響
- 沒有對應，但可在不嚴重影響效能的情況下建立對應關係 初始化部分
- 不需要對應、對成效也沒關係，並且可以建立 執行快取作業的臨時對應。
使用者可能遇到以下情形：
- 沒有對應關係。
- 沒有對效能至關重要的初始化點，可對應 可以建立
- 在執行快取作業時，效能也很重要。
對現有使用者和不支援的潛在使用者 我們可以看看一些替代方案，瞭解如何完全移除快取作業。
為所有 VMO 移除
移除所有 VMO 的快取作業會提供統一 API， 避免程式碼可能失敗的情況，因為先前 VM 上的實體 VMO 卻只列出預期連結的 VMO
遺憾的是，在某些情況下 可能會提供給服務驅動程式庫式的常見模式 而且不需建立對應關係，即可釘選並傳送至 VM 基礎硬體在此情況下，用戶端寫入的資料可能需要 可透過快取作業清理至記憶體但在固定 VMO 之前 其基礎頁面可能會被核心變更，而轉譯任何先前快取 而且乾淨度不足只有驅動程式庫 (而非用戶端) 可以固定記憶體 代表驅動程式庫必須在釘選後執行快取作業。申請 但這麼做會增加驅動程式庫的不必要的負擔。
區分實體 VMO 的核心對應
核心可以建立一個獨立的對應，而非依賴 physmap， 並改為對這個對應的執行快取作業
這樣可以解決直接使用 physmap 問題，並解除封鎖所有相關核心 並確保系統對使用者進行假設性的效能至關重要 對應則不受影響
缺點：
- 必須分配其他頁面資料表，才能保持對應狀態，同時浪費 則會在記憶體中保留對應。實體 VMO 範圍相當大
- 增加核心複雜度，並持續允許使用者執行快取 對無效範圍造成錯誤。
臨時核心對應
執行 對應作業程式碼不過，這樣做幾乎沒有 但實際上並未高於執行暫時性對應的使用者 改善原始提案