| RFC-0252：No Physical VMO CacheOps | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 移除實體 VMO 上的快取作業。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-06-12 |
| 審查日期 (年-月-日) | 2024-07-18 |
摘要
移除直接在實體 VMO 上執行快取作業的功能。
提振精神
由於實體 VMO 的快取作業依賴 physmap，因此目前無法穩定運作。由於實體 VMO 只能透過對應進行操作，因此一律可改用現有的 zx_cache_flush 作業。
實體 VMO 通常代表實體位址空間的非 RAM 區域，例如 MMIO 暫存器。執行快取作業最多是毫無意義，最糟的情況則是發生嚴重錯誤，具體情況取決於架構和硬體。雖然實體 VMO 已經需要受限資源才能建立，但盡量減少使用者導致核心當機的方式仍是好事。
利害關係人
協助人員：
cpu@google.com
審查者：
mcgrathr@google.com、hansens@google.com、jbauman@google.com
已諮詢：
社交：
Zircon 核心/VM 團隊已討論過。
設計
由於 zx_cache_flush 已經存在並已實作，因此這項提案不需要建構任何新內容。因此，提案只是要移除對實體 VMO (即由 zx_vmo_create_physical 建立的 VMO) 的下列作業支援：
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 和分頁 VMO 之間的 API 不同，這並非理想情況，因為程式碼可能需要容許提供任一類型的 VMO。不過，實體 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 移除
移除所有 VMO 的快取作業可提供統一的 API，避免程式碼在收到實體 VMO 時可能失敗的情況，因為先前程式碼只預期會收到分頁 VMO。
很遺憾，常見模式是服務或驅動程式庫可能會取得 VMO，且不需要在釘選並傳遞至基礎硬體之前建立對應。在這種情況下，用戶端寫入的資料可能需要透過快取作業清除至記憶體。不過，在 VMO 固定之前，核心可能會變更其基礎頁面，導致先前清除的快取不足。只有驅動程式庫 (而非用戶端) 可以釘選記憶體，因此驅動程式庫必須在釘選後執行快取作業。在這種情況下，要求對應會為驅動程式庫增加不必要的負擔。
實體 VMO 的獨立核心對應
核心可以為每個實體 VMO 建立個別的對應，並對這個對應執行快取作業，而不必依賴 physmap。
這項做法可解決 physmap 使用的直接問題、解除所有相關核心變更的封鎖，並確保沒有對應的假設性效能關鍵使用者不會受到影響。
缺點如下：
- 需要分配額外的頁面表格，才能保留這個對應，如果使用者有對應，就會浪費記憶體。實體 VMO 可能會涵蓋相當大的範圍。
- 增加核心複雜度，並持續允許使用者對無效範圍執行快取作業，可能導致核心發生錯誤。
暫時性核心對應
您可以在快取作業程式碼路徑中執行暫時對應，減輕頁面資料表的負擔。不過，這項做法與使用者自行執行暫時對應相比，好處並不多，因此實際上並未改善原始提案。