==> 在 [email protected] (ggg) 的文章中提到: > ※ 引述《[email protected] (Bug J.)》之銘言： > : 如果他辨識不出來，怎麼做轉換？ > 如果非常嚴謹的要求, 那麼 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 提供的機器就會. 我們試過在VMWare上在裝Xen，還跑得蠻高興的....除了速度外.... > 這樣講, 或許太咬文嚼字, 但這純脆是 Full Virtualization 的定義與適用 > 範圍. 如果要用 VM 做硬體界面的使用與組語教學, 這狀況就會像上述情況, 那 > 部份是被改過的(或許 VMware 就是一種透過軟體的改良, 而 XEN 就像是事前塗 > 改進行改善)或是受到限制無效的, 就有必要事先知道其侷限性. 很抱歉，目前本校就是利用virtual machine教寫組語，原本能動的都可以動， 原本不能動的還是不能動 > : 可以做，但是有沒有必要？ > 有下層實體在, 其實是可以不必模擬, 這是資源配置與共用的問題, 如果是已 > 經被配屬就轉到宿主 OS 請他代勞執行後回覆就行了, 這還能較跟實體逼真. > 但, VMware 做 Standard Logic Device 的模擬並無不好, 反而會讓上層的寄 > 居 OS 更容易就模擬的硬體快速安裝, 這是很多人愛用的原因之一. > 可是, 就教學使用界面與組語言, 如模擬成較高層的 Logic Device , 這就變 > 得太虛了 ! 我們現在教學就是這樣用，用法也都必須照模擬出來的那一張卡，沒什麼虛的 > : 所以？ > 很想知道現在是不是還有留下人在注意 Emulation 這一塊(電子所時代是做 > PDP-11 Bit Slice CPU Emulater 起家的). -- * Origin: ★ 交通大學資訊科學系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>