※ 引述《[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