※ 引述《[email protected] (Bug J.)》之銘言： : > 現在的 VMware 及 Connectix 是使用軟體程式的模擬, 而基本上, : > Binary Translation 技術是替換原指令碼為另一套程式, 由之 "代替" 執行. 換 : > 言之, 原指令碼等於消失了, 原來的 硬體processor指令 就等於未被虛擬化, 也 : > 可以說那些替換的指令未被辨識後再解譯. : 如果他辨識不出來，怎麼做轉換？ 如果非常嚴謹的要求, 那麼 Full Virtualization 應該是完全呈現一個 下層的實體實況給上層的 OS 與 AP 來用, 指令若有缺陷那也得反應. 如此一來, 要造成攔截產生 trap 的, 就是VMM 之上的虛擬機之間會互相 干擾的部份. 這部份就是 sensitive instruction 的部份. 如果沒有 sensitive instruction 的 trap 硬體支援, 就只剩用 interprter 針對每個指令都攔來檢驗後, 對應執行一途. 這就相當於所有指令全部都 trap, 但這樣太慢, 所以用 Binary Translation , Just In-time Compilation 加速. 可是還是太慢, 在 ring 1,2,3 執行時, X86 對 sensitive 指令多數會 trap, 只有 Ring 0 (就是 OS Kernel 部份)不及格, 這部份就用 BT interpreter , 但若是 VM1 之上再跑個 VM2 (Recusive VM)就碰到 VM2 相當於是 VM1 的 AP Ring 0 的 AP 是否用 BT & Interpreter 來跑, 就再掉回必須針對 VM2 再加 裝 BT & interpreter 於其上. 也就是說模擬出來的是 Interpreter 提供的機 器, 其性質已經不是下層實體的機器擁有的. 因為實體機器對部份敏感指令不 會產生 trap , 但 BT & interpreter 提供的機器就會. 這樣講, 或許太咬文嚼字, 但這純脆是 Full Virtualization 的定義與適用 範圍. 如果要用 VM 做硬體界面的使用與組語教學, 這狀況就會像上述情況, 那 部份是被改過的(或許 VMware 就是一種透過軟體的改良, 而 XEN 就像是事前塗 改進行改善)或是受到限制無效的, 就有必要事先知道其侷限性. : 既然講過X86最初設計上會有sentive指令不屬於priviledge指令的的狀況， : 那勢必這些指令必須被trap，所以必須轉換，這是理所當然的，況且他是runtime改， : 對使用者而言他是沒感覺的，我只要能夠保證guest感覺 : 「這是世界是一樣的」那就是虛擬化 ... : 現在每一個都是這樣做，即使是XEN在HVM的架構，他也是模擬一張常見的卡 : 而不是直接把下層的卡模擬給guest : 因為你要給上面的是「有NIC」，但是要模擬成那一塊NIC沒有規定， : 我只保證你在用這張卡的時候，所有的動作動作和response都會依照 : 我所模擬出來的卡，而你也不需要從寫driver這樣就可以了， : 對你不會有任何影響，這對guest來說，就是一個和真實一樣的環境 : 試想你為了要模擬出這一個NIC，你就必須把這NIC相關的protocol、SPEC瞭解清楚， : 因為你必須能夠模擬出所有動作，只要有一個不對，那就是不對， : 如果像你說的「所有NIC都要模擬」或是「所有音效卡都要模擬」， : 可以做，但是有沒有必要？ 有下層實體在, 其實是可以不必模擬, 這是資源配置與共用的問題, 如果是已 經被配屬就轉到宿主 OS 請他代勞執行後回覆就行了, 這還能較跟實體逼真. 但, VMware 做 Standard Logic Device 的模擬並無不好, 反而會讓上層的寄 居 OS 更容易就模擬的硬體快速安裝, 這是很多人愛用的原因之一. 可是, 就教學使用界面與組語言, 如模擬成較高層的 Logic Device , 這就變 得太虛了 ! : > 電通所以前有做 SPARC CPU 計畫是專做硬體與 系統 OS 的. : 所以？ 很想知道現在是不是還有留下人在注意 Emulation 這一塊(電子所時代是做 PDP-11 Bit Slice CPU Emulater 起家的). --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.5.5