为什么要在微控制器上使用虚拟化技术？
虚拟化是一种可以模拟出多套 逻辑硬件并允许多个操作系统或裸机程序共存于同一个物理硬件平台的技术。 在 PC 架构上，VMware 和 Virtual Box 已经有数十年历史，深刻地塑造了我们的 IT 基础设施。RVM 把同样的思想带到微控制器上——但理由是嵌入式系统特有的。
虚拟化有两种主要方式：全虚拟化可以运行完全无修改的二进制代码； 准虚拟化则要求操作系统底层被适当修改以运行于虚拟机上。RVM 使用 准虚拟化技术来减小运行时间消耗和内存消耗，提供一系列 超级调用来提供敏感的特权级操作。
在微控制器上，使用虚拟化技术的理由主要有三个。
可靠性
RTOS 通常使用静态代码分析和认证来确保系统的可靠性。然而这对很多应用 场景来说是不够的——除了 RTOS 自身之外，以下各项也会在系统中引入错误：
- 应用程序编码错误。 传统 RTOS 不提供任何形式的内存隔离，一个任务 内的错误会很容易传播到其他任务，然后毁掉整个软件系统。
- 辐射和电磁干扰。 这些外部干扰会翻转硬件状态位，在整个系统中造成 偶发错误。
- 拒绝服务。 一个高优先级任务如果在某个循环中死机，可能导致整个系统 失去响应；如果它频繁调用可能导致锁调度器的系统调用，必然摧毁整个系统 的实时性。
- 人为破坏。 系统没有内存保护，黑客可以侵入 IoT 设备并任意破坏其 功能。
看门狗定时器重启只能缓解低复杂度系统的问题。对于不能容忍完全重启的复杂 或关键应用，传统 RTOS 束手无策——而具备按虚拟机隔离能力的监视器可以。
安全性
传统 RTOS 通常不把信息安全作为设计目标，一个缓冲区溢出攻击通常就足以 夺取控制权，而后果可能比简单破坏糟糕得多：
- 智能家居的摄像头和家用电器可能被劫持。
- 智能汽车上，攻击者已经迫使驾驶员做出非预期行为——这在量产车上发生过。
- 医用呼吸机这类生命支持设备，把它关掉就足够致命。
- 关键工业应用中，整条生产线可能被停止。
虚拟机先天安全和模块化，底层的 RME 系统还提供了基于权能的安全机制。
灵活性
嵌入式软件市场长久以来都是碎片化的：互不兼容的 RTOS 和软件栈各自面向 不同市场。在过去这完全没问题，因为嵌入式系统一直是针对特定用途设计的 ——但如今 IoT 设备面临越来越多的功能整合需求。
与其开发一个具备所有功能的 RTOS，不如用虚拟化技术让不同的软件栈共存于 同一颗芯片。这会打开新世界的大门，允许构建全新的应用形式，而且工程师 不必改变已有的 RTOS 开发心智模式——基本没有学习成本。
虚拟化不会有很高的开销吗？
不会。 如果虚拟机监视器被设计得很好、使用方法也正确（尤其指通信 机制），虚拟化的开支可以忽略不计。虚拟化后的 FreeRTOS 线程切换和中断 响应时间约为裸机版的 4 倍——却仍比 RT-Linux 快整整 约 25 倍。 对于 CPU 占用高而 I/O 占用低的虚拟机，这开销更是可以忽略不计。
线程切换和中断响应时间膨胀了约 4 倍，能行吗？
在 RVM 支持的微控制器上，没问题。该虚拟机监视器面向高端 MCU， 其裸机响应速度已经远超很多传感器和执行器的实际所需。一个运行在 180MHz Cortex-M4 上的虚拟化 FreeRTOS，其中断响应时间和线程切换时间 与运行在 72MHz Cortex-M3 上的原生 FreeRTOS 差不多。
在 I/O 响应时间方面，Cortex-M3 已经足够优秀——我们选择 M4 是为了 增强的计算性能，不是为了响应时间。如果你的应用确实需要极低响应 时间，可以编写 RME 原生应用，其响应时间与 FreeRTOS 相当。使用比 Cortex-M4 更快的处理器（如 Cortex-M7、TMS320C66X）时，完全可以忽略 额外开销的问题。