| RFC-0252：沒有實體 VMO CacheOps | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 移除實體 VMOs 上的快取作業。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2024-06-12 |
| 審查日期 (年-月-日) | 2024-07-18 |
摘要
移除直接在實體 VMO 上執行快取作業的功能。
提振精神
實體 VMOs 上的快取作業目前無法正常運作，因為它們依賴 physmap。由於實體 VMOs 只能透過對應操作，因此可以隨時改用現有的 zx_cache_flush 作業。
實體 VMOs 通常代表實體位址空間的非 RAM 區域，例如 MMIO 暫存器。執行快取作業的結果，最好是毫無意義，最糟的情況是發生致命錯誤，這取決於架構和硬體。雖然實體 VMOs 已要求建立受限資源，但盡量減少使用者導致核心當機的方式仍是好事。
相關人員
協助人員：
cpu@google.com
審查者：
mcgrathr@google.com、hansens@google.com、jbauman@google.com
諮詢：
社會化：
已在 Zircon 核心/VM 團隊之間討論。
設計
zx_cache_flush 已存在且已導入，因此這項提案不需要建構任何新內容。因此，這項提案只是針對實體 VMOs (即由 zx_vmo_create_physical 建立的 VMOs) 移除下列作業的支援：
ZX_VMO_OP_CACHE_SYNCZX_VMO_OP_CACHE_INVALIDATEZX_VMO_OP_CACHE_CLEANZX_VMO_OP_CACHE_CLEAN_INVALIDATE
對非實體 VMOs 執行的這些作業 (也就是透過 zx_vmo_create、zx_vmo_create_contiguous、zx_vmo_create_child 或 zx_pager_create_vmo 建立的作業) 將保持不變，並且會像先前一樣運作。
這會導致實體 VMOs 和分頁式 VMOs 之間的 API 不一致，這並非理想情況，因為程式碼可能需要容許這兩種情況。不過，實體 VMO 並未廣泛使用，且目前無法從所有 VMO 移除快取作業，因此需要支援這兩種 VMO 的程式碼必須確保可使用對應項目。
實作
樹狀結構中實體 VMO 快取作業的用途不多，因為需要快取作業的大部分位置都已使用偏好的 zx_cache_flush。在 VMO 快取作業的現有用途中，總會有可用於 zx_cache_flush 的現有對應項目，因此遷移作業就會變得簡單。
因此，實施計畫如下：
- 遷移任何涉及實體 VMOs 的現有 VMO 快取作業用途。
- 在實體 VMOs 上停用快取作業，並讓這些作業傳回
ZX_ERR_NOT_SUPPORTED。
成效
使用 zx_cache_flush 執行快取作業應該比執行系統呼叫更有效率，因此這項變更通常會帶來淨效能提升。這項做法的例外狀況是，如果需要建立對應項目，但實體 VMOs 不常使用，目前也沒有這種情況。如有需要，我們日後會重新考慮這項決定。
人體工學
目前大多數快取作業都已使用 zx_cache_flush 執行，因為在可行情況下，使用 zx_cache_flush 更簡單、更方便，且從人體工學的角度來看，總是比 VMO 作業更受青睞。不過，如果對應項目尚未存在，這項做法就會變得非常不人性化。
回溯相容性
這是 API 重大變更，但快取作業是由少數使用者 (通常是驅動程式和類似程式) 執行，而且只有少數使用者有實體 VMOs，因此對現有程式碼來說，應不難進行遷移。
安全性考量
此提案會從核心移除程式碼和邏輯，並在使用者在特權模式下執行時，避免使用者控制的快取作業發生在潛在的裝置記憶體中。因此，從安全性角度來看，這項功能的評價介於中立和略為正面之間。
缺點、替代方案和未知事項
這項提案假設實體 VMOs 快取作業的使用者會：
- 既然已建立對應，因此切換至在對應上執行快取作業，可提升效能，且沒有任何缺點。
- 沒有對應項目，但可以在非效能關鍵的初始化區段中建立對應項目。
- 沒有對應項目，對效能影響不大，且可以建立暫時對應項目來執行快取作業。
可能有使用者：
- 沒有對應項目。
- 沒有可建立對應的非效能關鍵初始化點。
- 否則，執行快取作業時，效能會受到嚴重影響。
考量到現有使用者和不支援的潛在使用者，我們可以考慮一些完全移除快取作業的替代方案。
為所有 VMOs 移除
為所有 VMOs 移除快取作業可提供一致的 API，避免在先前只預期分頁式 VMOs 的情況下，程式碼可能失敗的情況。
很遺憾，在某些常見的模式中，服務或驅動程式庫可能會獲得 VMO，而無需在綁定並傳遞至基礎硬體之前建立對應項目。在這種情況下，用戶端寫入的資料可能需要透過快取作業清除至記憶體。不過，在 VMO 固定之前，其底層頁面可能會遭核心變更，導致先前清除快取的效果不佳。由於只有驅動程式庫 (而非用戶端) 可以綁定記憶體，因此驅動程式庫必須在綁定後執行快取作業。在這種情況下，要求對應項目執行這項操作，會為驅動程式庫增加不必要的額外負擔。
為實體 VMOs 提供獨立的核心對應
核心可以為每個實體 VMO 建立個別對應項目，而非依賴 physmap，並對此對應項目執行快取作業。
這確實解決了 physmap 用法的直接問題，解除所有相關核心變更，並確保沒有對應的假設效能重要使用者不會受到影響。
缺點如下：
- 需要分配其他頁面表格才能保留此對應項目，如果使用者有對應項目，這會浪費記憶體。實體 VMOs 的範圍可能相當廣泛。
- 增加核心複雜度，並繼續允許使用者在可能導致核心錯誤的無效範圍上執行快取作業。
臨時核心對應
只要在快取作業程式碼路徑中執行暫時對應作業，即可減輕頁面表格的額外負擔。不過，相較於使用者自行執行暫時對應作業，這項做法幾乎沒有任何好處，因此並未實際改善原始提案。