RFC-0253：zx_object_get_info ZX_INFO_VMAR_MAPS

問題陳述

如果呼叫端只關心一個 VMAR，ZX_INFO_PROCESS_MAPS 就會效率不彰。

ZX_INFO_PROCESS_MAPS 會對程序的位址空間進行疊代，為呼叫端提供 zx_info_maps_t 結構體，說明每個位址區域和可供程序使用的對應項目。如果呼叫端只需要這項資訊的一部分，例如特定 VMAR 的內容，仍須支付全額費用。更糟的是，呼叫端必須篩選結果。

摘要

我們建議新增 object_info 主題 ZX_INFO_VMAR_MAPS，其行為類似 ZX_INFO_PROCESS_MAPS，但適用於 VMAR。

相關人員

誰會受到這項 RFC 是否通過的影響？(此為選用部分，但建議您填寫)。

協助人員：

審查者：adamperry@ (Starnix)、adanis@ (Zircon VM)、dworsham@ (Zircon VM)、mcgrathr@ (Zircon)

社會化：在起草此 RFC 前，我們曾與 adamperry@ 和 adanis@ 簡短討論過這項提案。

需求條件

本提案的目的，是讓 Starnix 能夠查詢特定 VMAR (Linux 程序位址空間，又稱為受限制區域)，而非整個程序的位址空間，藉此提升 Starnix 效能。

效率：新系統呼叫應以指定 VMAR 的大小/複雜度為比例，執行工作。

對稱性和人體工學：新呼叫產生的結果，應在結構上與現有 ZX_INFO_PROCESS_MAPS 產生的結果相似，以便盡量減少想使用新呼叫的現有呼叫端的工作量。

設計

我們將新增名為 ZX_INFO_VMAR_MAPS 的新 object_info 主題。這個新主題的運作方式與現有的 ZX_INFO_PROCESS_MAPS 相同，但不會傳回指定程序的結果，而是傳回指定 VMAR 的結果。

與 ZX_INFO_PROCESS_MAPS 一樣，結果會是深度優先預先順序的遍歷。

第一筆結果記錄會說明指定的 VMAR。

與 ZX_INFO_PROCESS_MAPS 不同，結果的深度欄位會相對於指定的 VMAR，而非指定的程序。第一筆結果記錄的深度為 0。

舉例來說，object_get_info 的更新說明文件會說明以下內容：

If *topic* is `ZX_INFO_VMAR_MAPS`, *handle* must be of type `ZX_OBJ_TYPE_VMAR`
and have `ZX_RIGHT_INSPECT`.

和

### ZX_INFO_VMAR_MAPS

*handle* type: `VM Address Region`, with `ZX_RIGHT_INSPECT`

*buffer* type: `zx_info_maps_t[n]`

The `zx_info_maps_t` array is a depth-first pre-order walk of the target
VMAR tree. As per the pre-order traversal base addresses will be in ascending
order.

See `ZX_INFO_PROCESS_MAPS` for a description of `zx_info_maps_t`.

The first `zx_info_maps_t` will describe the queried VMAR. The *depth*
field of each entry describes its relationship to the nodes that come
before it. The queried VMAR will have depth 0. All other entries have
depth 1 or greater.

Additional errors:

*   `ZX_ERR_ACCESS_DENIED`: If the appropriate rights are missing.
*   `ZX_ERR_BAD_STATE`: If the target process containing the VMAR has
    terminated, or if the address space containing the VMAR has been
    destroyed.

實作

這項新功能將透過一系列小型且回溯相容的變更 (包括測試和說明文件的更新) 實作。部分現有程式碼會重構，以便同時用於 ZX_INFO_PROCESS_MAPS 和 ZX_INFO_VMAR_MAPS。

成效

不會影響現有的程式碼/系統。完成後，從 ZX_INFO_PROCESS_MAPS 遷移至 ZX_INFO_VMAR_MAPS 的呼叫端應可見效能提升，因為系統會減少系統呼叫執行的工作，並消除任何呼叫後篩選步驟。

人體工學

為方便使用，結果類型和語意會與現有呼叫 object_get_info 與 ZX_INFO_PROCESS_MAPS 的類型和語意相近。

回溯相容性

建議的變更可回溯相容。現有通話不會受到影響。新通話的行為類似於現有通話。

安全性考量

由於傳回的資訊是 ZX_INFO_PROCESS_MAPS 傳回的子集，且新的 object_get_info 呼叫需要與現有 ZX_INFO_PROCESS_MAPS 呼叫相同的句柄權限，因此安全性途徑或狀態不會有所變更。

隱私權注意事項

沒有隱私權疑慮。

測試

核心測試套件會更新，以便測試新的呼叫。

說明文件

系統會更新系統呼叫文件，說明新的呼叫。

缺點、替代方案和未知事項

實作這項提案只需要少量工程資源。新系統呼叫的未來維護工作應盡量減少。此外，新呼叫不會大幅降低 (核心實作) 彈性或 (API) 自由。

實作新主題的主要替代做法，就是繼續使用效率較低的 ZX_INFO_PROCESS_MAPS，並繼續篩選結果。

相對於目標和位址空間的深度

根據這項提案，系統會針對每個造訪節點回報的深度欄位，相對於指定的 VMAR 目標，從零開始。

另一種做法是回報相對於程序位址空間的深度。也就是回報絕對深度。這兩個選項都符合要求，且在達成目標方面表現相似。

我們選擇以目標為依據的深度，是因為這樣可向呼叫端公開的資訊較少，且在內部鎖定策略方面，也能提供更靈活的實作方式。

既有技術與參考資料

另請參閱 ZX_INFO_PROCESS_MAPS 和 ZX_INFO_VMAR。