==> 在 [email protected] (ggg) 的文章中提到: > ※ 引述《[email protected] (Bug J.)》之銘言： > : 有吧，參考xen的原始paper，在2003年sosp發表 > : http://www.cl.cam.ac.uk/research/srg/netos/papers/2003-xensosp.pdf > : 請翻到第二頁的2. XEN: APPROACH & OVERVIEW，在該段的第二行就有用到這個詞， > : 而整篇PAPER這個詞也出現了7次 > 把出現的地方再看了一下, Full Virtualization 是指提供全部硬體的虛擬化, > 在出現相關研究的地方提到了 最早的 IBM VM/370 及 VMware 及 Connectix , > "All of these examples implement a full virtualization of (at least a > subset of) the underlying hardware ". > 印象中, 就不是很認定 VMware 及 Connectix 是其稱呼的 Full Virtualization > 這個括弧留下的印象是作者 對 VMware 及 Connectix 的 Full Virtualization > 是有點保留的. 因為最早的 VM 使用 Microprogramming 技術, 稱為 Emulation > 是硬體指令層的攔截與解譯, 而不用通稱的 Simulation , 後者是習慣被用於軟 > 體程式的模擬. 現在的 VMware 及 Connectix 是使用軟體程式的模擬, 而基本上, > Binary Translation 技術是替換原指令碼為另一套程式, 由之 "代替" 執行. 換 > 言之, 原指令碼等於消失了, 原來的 硬體processor指令 就等於未被虛擬化, 也 > 可以說那些替換的指令未被辨識後再解譯. 如果他辨識不出來，怎麼做轉換？ 既然講過X86最初設計上會有sentive指令不屬於priviledge指令的的狀況， 那勢必這些指令必須被trap，所以必須轉換，這是理所當然的，況且他是runtime改， 對使用者而言他是沒感覺的，我只要能夠保證guest感覺 「這是世界是一樣的」那就是虛擬化 > 不過, XEN 強調其新創的 paravirtualization , 對於 VMware 及 Connectix > 是否如宣稱的 "全虛擬", XEN 確也沒必要去爭論. 但嚴格看來, XEN , VMware , > 及被微軟買下的 Connectix 都是針對虛擬缺陷的部份用 "事先取代法" 替換掉 , > 也都不是 "全虛擬實層硬體". 個人覺得會出現這種困擾的原因是 VM386 在提供虛 > 擬化時, 不是沒提供而是沒作完整, 所以 VMware 跟 Connectix 的做法就相當於 > 有一部份使用硬體的功能, 然後把硬體未提供完整的那部份敏感指令用軟體給替換 > 掉了. 所以在上層的寄居 OS 所提供的執行環境裡, 程式裡若用到有缺陷的敏感性 > 指令還是不會有實層硬體的虛擬支援. 也就是 "非完整的全虛擬化". 如果不是 > X86 CPU 只剩缺陷, BT 技術在無虛擬硬體支援的 CPU 裡使用是效率不高的. 相對 > 言, paravirtualization 的直接替代就會高效率. VMware 應該也會用這種 "病 > 毒式轉向替代法"(這是指不用 source code 重編譯的強行替代法, 也就是 binary > modification). > 這個 X86 的缺陷與困擾可參考 > http://www.i.u-tokyo.ac.jp/edu/training/ss/msprojects/data/ > 06-VirtualMachineArchitecture.pdf 其實X86的缺陷，已經很多論文都提過了，建議你看論文會比較詳細 > VMware 的概念應該是提供下層硬體相容的 Logical Machine , 而非下層硬體 > 的 Full Virtualization. 她是提供給上層寄居OS一種市場較普及化裝置的虛 > 擬, 而非下層實體裝置的虛擬. > 譬如 音效卡 就是模擬 Creative Sound Blaster 而非實體裝置. 現在每一個都是這樣做，即使是XEN在HVM的架構，他也是模擬一張常見的卡 而不是直接把下層的卡模擬給guest 因為你要給上面的是「有NIC」，但是要模擬成那一塊NIC沒有規定， 我只保證你在用這張卡的時候，所有的動作動作和response都會依照 我所模擬出來的卡，而你也不需要從寫driver這樣就可以了， 對你不會有任何影響，這對guest來說，就是一個和真實一樣的環境 試想你為了要模擬出這一個NIC，你就必須把這NIC相關的protocol、SPEC瞭解清楚， 因為你必須能夠模擬出所有動作，只要有一個不對，那就是不對， 如果像你說的「所有NIC都要模擬」或是「所有音效卡都要模擬」， 可以做，但是有沒有必要？ 而這些guest 對virtual NIC所下的命令，則必須全部轉成real NIC的命令， 這時候就需要ESX VMM裡的driver或是XEN domain0的driver， 這兩個用的driver在層次上是有差距的，一個是包在VMM， 但是VMM是你自己寫的，所以DRIVER MODEL就可能和LINUX和WINDOWS...不一樣， （事實上也不一樣） 因此會造成你必須從寫，而如果是XEN的方式，他是沿用Linux的driver， 但是因為你的driver是放在一個domain裡，所以也必須等到那個domain被 schedule到，才能下真的IO，反觀ESX，因為他是在VMM，因此當guest下request， 他可以真的馬上處理，一樣，各有優缺點 > 這也就是 sensitive instruction 不容易事先被辨認出來的原因. 我到覺得不難....只是當初設計上是不是對virtualization設計而已 > 問題是發生在 ring 0 的 emulation , 不是可不可以看到 status, 而是要虛擬 > 出一個 "如假包換" 的環境, 要讓 guest os 覺得是在 ring 0. > : 實際上在現今的VT和V技術，BIOS不用特地支援，但是在IA-64上卻需要， > : 因此你這一點如果針對IA-64是對的，IA-32是有疑問的 > 這個功能要在 bios 開機設定時被啟動, AMD-V 是 default 為 enable. 我一樣可以在事後在系統初始化時在進去，這樣並不需要BIOS真的配合， IA-64卻不是 > : 通訊所和這有什麼關係..... > 電通所以前有做 SPARC CPU 計畫是專做硬體與 系統 OS 的. 所以？ -- * Origin: ★ 交通大學資訊科學系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>