==> 在 [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>