RFC-0128：推出「zx_vcpu_kick」

RFC-0128：引入 `zx_vcpu_kick`
狀態已接受
領域
  • 核心
說明

新的 syscall「zx_vcpu_kick」可能會導致執行中的 VCPU 退出主機並返回使用者空間。
毛皮變化
作者
審查人員
提交日期 (年-月-日)2021-08-26
審查日期 (年-月-日)2021-09-25

編輯此 RFC

編輯 RFC 中繼資料

摘要

建議您新增 zx_vcpu_kick 的 syscall，這可能會產生執行中的 vCPU 離開主機並返回使用者空間。此外，我們建議重新命名 zx_vcpu_resume 變更為 zx_vcpu_enter，以保持一致的命名法。

提振精神

vCPU 執行時，可能會在呼叫 zx_vcpu_enter。這會導致虛擬機器管理員發生問題， 明確關閉 VCPU，虛擬機器管理員需透過系統呼叫 可控制呼叫執行緒，以安全地釋放所有相關 再複習一下，機構節點 是所有 Google Cloud Platform 資源的根節點

此外，為了簡化整合測試 而更便利的方法，就是強制要求 VCPU 退出訪客。如此一來 可以更簡潔扼要地撰寫測試

相關人員

講師：CPU

審查員：adanis、tamird、jamesr

諮詢：dgreenaway、brunodalbo

社交：我們在即時通訊執行緒中討論了設計。 為連線能力團隊解決網路應用層所面臨的問題 測試。

設計

本提案包含下列有關 Zircon syscall 介面的變更：

  1. 新增 zx_vcpu_kick
  2. 正在將「zx_vcpu_resume」重新命名為「zx_vcpu_enter」

其中 zx_vcpu_enter 和 zx_vcpu_kick 會定義為：

/// Enter a VCPU, and start or continue execution.
/// Rights: handle must be of type ZX_OBJ_TYPE_VCPU and have ZX_RIGHT_EXECUTE.
// @blocking
zx_status_t zx_vcpu_enter(
    zx_handle_t handle,
    uint32_t options,
    zx_port_packet_t* packet
);

/// Exit from the current or next call to |vcpu_enter|.
/// Rights: handle must be of type ZX_OBJ_TYPE_VCPU and have ZX_RIGHT_EXECUTE.
zx_status_t zx_vcpu_kick(
    zx_handle_t handle
);

在 vCPU 處理常式上呼叫 zx_vcpu_kick 時，任何目前執行中的呼叫 相同帳號代碼的 zx_vcpu_enter 會傳回 ZX_ERR_CANCELED。此外 如果 zx_vcpu_enter 在呼叫 zx_vcpu_kick 時並未執行， 下一次呼叫 zx_vcpu_enter 時會立即傳回 ZX_ERR_CANCELED。這個 可讓虛擬機器管理員呼叫 zx_vcpu_kick zx_vcpu_enter 會傳回 ZX_ERR_CANCELED。相反地 如果 zx_vcpu_enter 尚未傳回 ZX_ERR_CANCELED，則只會傳回此值 一次，無論呼叫多少次 zx_vcpu_kick 都一樣。

已選擇「ZX_ERR_CANCELED」做為要傳回的狀態，因此導致結束 比虛擬機器管理員容易區分這樣一來 虛擬機器管理員，以使用該狀態來妥善停止 vCPU， 在虛擬機器管理員中執行額外狀態管理發現時機 zx_vcpu_enter 已傳回 ZX_ERR_CANCELED，即可關閉 vCPU 或釋放任何其他相關資源

此外，zx_vcpu_kick 的行為是停止 vCPU，但並非強制停止 vCPU 終止服務這表示虛擬機器管理員可能會在 zx_vcpu_enter之後的 vCPU 會傳回 ZX_ERR_CANCELED，方法是呼叫 zx_vcpu_enter。除了處理傳回值及略過 因此虛擬機器管理員不需要執行任何動作 特殊，可以立即呼叫 zx_vcpu_enter 來繼續執行作業。

實作

在管理程序中，zx_vcpu_enter 的模擬依據為 zx_port_wait。它有 幾乎相同的 API，但會有期限應等待 然後傳回包含該封包的使用者空間。 不同於 zx_thread_start，這不是建立新執行緒的方法 而非轉換目前的執行作業執行緒。

不過，我們認為不採用符記化的做法，例如 (位於 zx_task_suspend 中)，很適合中斷 vCPU 的執行作業。A 罩杯 符記式方法不符合 vCPU 的執行模型，但需要 使用者空間與核心之間的來回常數。

相反地，我們提議 zx_vcpu_kick 只會造成 zx_vcpu_enter 傳回 使用者空間並傳回錯誤代碼，表明連線中斷。在 因此，zx_vcpu_kick 的實作方式會非常類似 zx_vcpu_interrupt。該指令會執行以下動作：

  1. 設定狀態。如果是 zx_vcpu_kick，這個狀態是用來 表示 VCPU 應在離開訪客時傳回。這個變數 方法是使用 zx_object_get_info，並將主題設為 ZX_INFO_VCPU 和對應的 zx_info_vcpu_t 類型。
  2. 確認 vCPU 是否正在執行；如果是，請 IPIs 實體 CPU 告訴 CPU 正在執行的原因這會強制 vCPU 結束 進而讓服務中斷 傳回值。

原子佈林值會追蹤是否已呼叫 zx_vcpu_kick，以及 VCPU 應傳回 ZX_ERR_CANCELED，直到沒有任何未付款項 返回使用者空間。也就是說 使用者空間內的訪客封包，則在傳回檔案前， ZX_ERR_CANCELED，稍後呼叫 zx_vcpu_enter。

這個方法讓 zx_vcpu_enter 的行為類似於 zx_port_wait 發生逾時情形

該實作程序將在單一 CL 中執行，也就是 Fuchsia 存放區內包含管理程序。這項異動將包括 更新 syscall 的說明文件和語言繫結，以及 管理程序和虛擬機器管理員

成效

除了誘使訪客離開外，對效能沒有任何已知影響 執行任務主要用途是 就會產生實際的影響

人體工學

討論了zx_vcpu_enter和zx_vcpu_kick的人體工學注意事項 「design」部分。

回溯相容性

管理程序的所有已知使用者都包含在 Fuchsia 存放區中 因此，只要導入 zx_vcpu_kick 並重新命名 zx_vcpu_resume 到 zx_vcpu_enter。

安全性考量

應稽核使用 zx_vcpu_kick 的虛擬機器管理工具，以確保 使用 zx_vcpu_enter 時，ZX_ERR_CANCELED 返回 且必須將傳回的 PortPacket 忽略，才能 重新啟用 vCPU 的作業。如果沒有忽略 PortPacket， 會針對已為零的無效資料執行作業 (任何錯誤皆為 true) 狀態是由 zx_vcpu_enter 傳回。

隱私權注意事項

此提案對隱私權沒有任何影響。

測試

實作 CL 登陸後，我們就可以為 測試能否順利關閉虛擬機器 ASAN 故障。

說明文件

我們需要為 zx_vcpu_kick syscall 新增額外說明文件，且 我們需要展開 zx_vcpu_enter Syscall 的說明文件 納入新的退貨狀態和 PortPacket 個處理建議。

缺點、替代方案和未知

這個提案的缺點是發起了額外的系統呼叫。這項服務 我們可以重複使用 zx_task_kill 或 zx_handle_close，但兩者都有各自的缺點。

如要專門設定 zx_task_kill 來使用 vCPU，我們必須考慮 將 vCPU 視為工作，因此讓所有與工作相關的系統呼叫都能使用 VCPU。 如果我們只讓 zx_task_kill 支援 vCPU，其他兩者都無法使用 這就不成問題

因此，我們可以依賴 zx_handle_close 的語意，並新增 on_zero_handles 處理常式至 VcpuDispatcher。這樣一來，我們就能 終止 vCPU 數量。不過，這種做法 缺點：VCPU 停止後即無法再繼續執行 並使 VCPU 控制代碼失效撤銷 vCPU 處理常式為 更是如此，因為這是固有的競速模式。其他執行緒 可能正在使用 VCPU 處理常式插入並中斷 處理常式無效，因而導致非預期的錯誤。

另一種做法是 zx_thread_cancel 範例，其中有任何特定執行緒上的封鎖作業 會立即傳回 ZX_ERR_CANCELED。如此一來，我們就能 以便日後使用類似 vCPU 的模型

既有藝術品和參考資料

Apple 的 Hypervisor 架構有類似的操作： https://developer.apple.com/documentation/hypervisor/1441468-hv_vcpu_interrupt

以及 Linux 的 KVM (核心型虛擬機器)： https://www.kernel.org/doc/html/latest/virt/kvm/vcpu-requests.html#vcpu-kicks