LWN：為什么RISC-V尚未支持KVM？
關(guān)注了就能看到更多這么棒的文章哦～
Why RISC-V doesn't (yet) support KVM
By Jonathan Corbet
May 20, 2021
DeepL assisted translation
https://lwn.net/Articles/856685/
近年來 RISC-V CPU 架構(gòu)的地位日益突出。其相對開放的性質(zhì)使其成為一個有吸引力的平臺，許多公司都在此基礎(chǔ)上開發(fā)了產(chǎn)品。Linux 很好地支持了 RISC-V，但有一個缺陷：一直沒能支持 KVM 虛擬化，盡管其實(shí)有了質(zhì)量很不錯的實(shí)現(xiàn)代碼了。最近一次人們嘗試增加這個功能支持的時(shí)候，人們從中看到了 RISC-V 生態(tài)系統(tǒng)有些地方似乎并不像人們希望的那樣能良好運(yùn)作。
Linux 支持許多虛擬化機(jī)制，但 KVM 通常被視為缺省解決方案（native solution）。它提供了跨系統(tǒng)的一套標(biāo)準(zhǔn)接口，但 KVM 中大部分內(nèi)容一定是跟特定架構(gòu)相關(guān)的，因?yàn)榫唧w的虛擬化支持機(jī)制在不同類型的處理器上都各不相同。因此，支持 KVM 的架構(gòu)里一般都有一個 kvm 目錄，跟此架構(gòu)中的其他那些架構(gòu)相關(guān)代碼放在一起。
鑒于此，當(dāng) Anup Patel 的 patch set 在增加對 RISC-V KVM 的支持并將這些特定架構(gòu)相關(guān)代碼存放在 staging 目錄中時(shí)，有些開發(fā)者的眉頭就皺了起來。staging 目錄通常用于存放那些不符合內(nèi)核代碼質(zhì)量標(biāo)準(zhǔn)的設(shè)備驅(qū)動。如果一切順利得到改進(jìn)的話，就會最終 "畢業(yè)" 離開 staging 目錄。它通常不用來放置架構(gòu)相關(guān)的代碼。所以 staging 目錄的維護(hù)者 Greg Kroah-Hartman 很快就回復(fù)郵件，詢問為什么要這樣做。
原因其實(shí)是來自 RISC-V 代碼的 patch 接受政策，可在 Documentation/riscv/patch-acceptance.rst 中找到，內(nèi)容如下：
我們只接受跟新的 module 或 extension 有關(guān)的 patch，并且前提是這些 module 或 extension 的規(guī)范（specification）被 RISC-V 基金會列為 "Frozen（凍結(jié)）" 或 "Ratified（批準(zhǔn)）"。當(dāng)然，開發(fā)者可以維護(hù)他們自己的 Linux 內(nèi)核代碼庫，其中可以存放包含了想要使用的任何 draft extension 相關(guān)的代碼）。
RISC-V 的虛擬化是由 hypervisor extension 這個規(guī)范進(jìn)行定義的。Patel 解釋說，這個 extension 還沒有得到批準(zhǔn)：
KVM RISC-V 的 patch 已經(jīng)在等待了將近 2 年了。人們不斷調(diào)整 RISC-V H-extension（hypervisor extension）的凍結(jié)時(shí)間，我們無法確定它何時(shí)會被凍結(jié)。事實(shí)上，很多人已經(jīng)在硬件里面實(shí)現(xiàn)了 RISC-V H-extension，KVM RISC-V 在這些真正存在的硬件上也可以正常使用。
將 KVM RISC-V 轉(zhuǎn)移到 drivers/staging 的話，在 RISC-V H-extension 被凍結(jié)之前，就可以繼續(xù)進(jìn)行 KVM RISC-V 的開發(fā)，同時(shí)也不會破壞 Linux RISC-V patch 接受政策。
Kroah-Hartman 對此不以為然。他表示，staging 目錄不是用來規(guī)避內(nèi)核代碼庫中其他模塊的一些自己政策的，所以 RISC-V KVM 代碼不能合入 staging。KVM 的總體維護(hù)者 Paolo Bonzini 補(bǔ)充說，從開發(fā)者不得不繞過這個政策的事實(shí)中就可以看出，"RISC-V 的 patch 接受政策是行不通的"。他說，尤其來說對于 RISC-V 的 KVM 實(shí)現(xiàn)是一個更加不幸的事情，因?yàn)檫@組 KVM 代碼 "質(zhì)量很高，展示了如何正確地實(shí)現(xiàn)代碼"。他還說道，可能有一些參與者會喜歡拖慢 patch 合入內(nèi)核的速度，從中獲益。
Kroah-Hartman 回應(yīng)說，拖慢合入有用代碼，這是 "可怕的" 做法，內(nèi)核社區(qū)的工作目標(biāo)是能讓硬件工作起來，而阻止合并那些能很好支持現(xiàn)有硬件的代碼的政策是沒有意義的。他要求 RISC-V 的維護(hù)者解釋這個政策，目前他們還沒有回答。不過，早在 4 月份的時(shí)候 RISC-V 的維護(hù)者 Palmer Dabbelt 就承認(rèn)，這個 patch 接受政策并沒有達(dá)到預(yù)期的效果：
我在 RISC-V 方面的目標(biāo)一直是致力于推動真正的產(chǎn)品出貨，并且是運(yùn)行一套盡可能接近上游代碼庫的 software stack。我認(rèn)為這是讓 software stack 實(shí)現(xiàn)可持續(xù)的維護(hù)的唯一途徑。這種 “只接受達(dá)到凍結(jié)狀態(tài)的 extension" 的政策是為了幫助實(shí)現(xiàn)這一目標(biāo)，引導(dǎo)供應(yīng)商共同建立一套我們可以支持的共同代碼，但實(shí)踐下來，這并沒有奏效。
他補(bǔ)充說，這個政策可能會改變，但需要先確認(rèn)出能讓大家達(dá)成一致都同意的新的 patch 接受政策時(shí)才能改。不過，聯(lián)合維護(hù)者（co-maintainer） Paul Walmsley 把責(zé)任歸咎于 RISC-V 組織的 specification 規(guī)范決定流程，認(rèn)為真正需要改變的是這個規(guī)范流程。
其實(shí)不難理解為什么 RISC-V 的維護(hù)者不愿意去支持所有各種非標(biāo)準(zhǔn)的 CPU。RISC-V 的開放性使得任何人都可以比較容易地創(chuàng)建他們自己的變體，而支持這些全部變種最終是不可行的。反過來說，正如 Kroah-Hartman 所說，內(nèi)核的目標(biāo)是要在現(xiàn)有的硬件上正常運(yùn)行。所以阻止支持那些已經(jīng)在售賣的系統(tǒng)的話，只會把這些系統(tǒng)的用戶推向由供應(yīng)商專門提供的內(nèi)核版本，其中會包含很多非 Linux kernel 官方的代碼，這對于一個本應(yīng)是開放的架構(gòu)來說是非常不幸的結(jié)果。
尤其是這里在討論的是像虛擬化這樣的基本功能都無法得到支持，因此這個問題變得更加緊迫。希望這個插曲能使得 RISC-V 架構(gòu)的 patch 接受政策進(jìn)行調(diào)整。否則的話，Kroah-Hartman 已經(jīng)表明如果沒有其他選擇的話，他愿意接受這些代碼合入 staging。因此，Linux 應(yīng)該還是會較短時(shí)間內(nèi)就能讓 KVM 支持 RISC-V，盡管這可能需要繞過該架構(gòu)的維護(hù)者。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～