==> 在 [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最初设计上会有sensitive指令不属於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>