1、虚拟化技术概述：MTK8678平台简介、虚拟化技术发展史、虚拟化核心概念、MTK虚拟化方案整体架构
各位同学，大家好。我是你们这堂课的讲师。在嵌入式这行摸爬滚打了十几年，从早期的单核单片机一路做到现在的多核异构SoC，说实话，虚拟化技术是我近几年觉得最值得投入精力去啃的一块硬骨头。
今天咱们开篇，先不急着敲代码。先把地基打牢。我会带大家看看MTK8678这个平台到底什么来头，再聊聊虚拟化这玩意儿是怎么一步步发展到今天的。最后，我们把MTK在虚拟化上的整体方案捋一遍。
1.1 MTK8678平台简介：一颗为虚拟化而生的芯
MTK8678，这颗芯片在车载和高端IoT领域名气不小。我去年参与的一个项目，客户点名要用它，原因很简单：算力够猛，而且原生支持硬件虚拟化。
它的核心配置是这样的：
- CPU架构：4颗Cortex-A78大核 + 4颗Cortex-A55小核。典型的big.LITTLE架构。
- 虚拟化扩展：ARMv8.4-A架构，支持VHE（Virtualization Host Extensions）。这意味着什么？意味着Guest OS可以直接跑在EL2上，省掉一层上下文切换的开销。
- GPU：Mali-G78 MC4，支持GPU虚拟化，可以切分给不同虚拟机使用。
- 内存：支持LPDDR5，最大32GB。我建议做多系统部署时，至少配8GB，否则跑两个Android实例会有点吃力。
- 外设：内置了硬件IOMMU（SMMU），可以给每个虚拟机分配独立的外设访问权限。
说白了，这颗芯片从硬件层面就做好了跑多个操作系统的准备。你不需要像早期那样，全靠软件去模拟硬件，性能损耗大得吓人。
核心要点：MTK8678的硬件虚拟化支持，是咱们这套方案能落地的基础。没有硬件层面的EL2和SMMU，后面讲的所有东西都是空中楼阁。
1.2 虚拟化技术发展史：从大型机到嵌入式
虚拟化不是新东西。我刚开始工作时，觉得这玩意儿是服务器领域的专利。后来才发现，嵌入式领域早就悄悄用上了。
咱们简单捋一下几个关键节点：
- 1960年代 - 大型机时代：IBM搞出了CP-40，目的是让一台昂贵的大型机能同时跑多个任务。那时候的虚拟化，纯粹是为了省钱。
- 1990年代 - x86虚拟化萌芽：VMware在x86上搞出了二进制翻译。为什么？因为x86架构天生对虚拟化不友好，有些敏感指令没法直接捕获。我记得当时看论文，觉得这帮人真是天才，硬是用软件把坑填上了。
- 2005年 - 硬件辅助虚拟化：Intel和AMD分别推出了VT-x和AMD-V。CPU开始原生支持虚拟化，Hypervisor的代码量一下子少了很多。
- 2010年代 - ARM虚拟化崛起：ARMv7-A开始引入虚拟化扩展。到了ARMv8，EL2异常级别成了标配。我在项目中遇到过，早期用Cortex-A7做虚拟化，性能损耗大概在15%左右。换成Cortex-A72后，损耗降到了5%以内。
- 现在 - 嵌入式虚拟化爆发：车载、工业、IoT，都在搞多系统融合。MTK8678就是这波浪潮的代表。
你想想看，为什么嵌入式现在需要虚拟化？因为一个系统要同时跑Android（娱乐）、Linux（控制）、RTOS（实时）。以前的做法是搞三块板子，现在一块芯片搞定。
1.3 虚拟化核心概念：Hypervisor、VM、Guest OS
这几个概念，我建议你把它刻在脑子里。后面所有章节都绕不开它们。
1.3.1 Hypervisor（虚拟机监视器）
Hypervisor，也叫VMM。它是个软件层，直接跑在硬件之上。它的职责就一个：管理所有虚拟机。
Hypervisor分两种：
- Type-1（裸机型）：直接跑在硬件上。比如Xen、KVM（当它跑在硬件上时）、ACRN。MTK的方案用的就是Type-1。
- Type-2（宿主型）：跑在操作系统之上。比如VMware Workstation、VirtualBox。性能差一些，但方便。
我个人习惯用Type-1做嵌入式。为什么？因为延迟低，资源独占。Type-2在嵌入式里基本没人用，你想想看，在Linux上再跑一个Linux，那性能损耗谁受得了？
1.3.2 VM（虚拟机）
VM就是一台虚拟出来的计算机。它有自己虚拟的CPU、内存、硬盘、网卡。在MTK8678上，一个VM可以独占一个Cortex-A78核心，也可以共享。
我曾经踩过一个坑：给一个VM分配了2个vCPU，但物理核心只有4个。结果另一个VM的实时任务被频繁抢占，导致音频卡顿。后来我改成1个VM独占1个物理核心，问题解决。
避坑指南：分配vCPU时，尽量让实时性要求高的VM独占物理核心。别搞超分，否则你会被客户骂到怀疑人生。
1.3.3 Guest OS（客户操作系统）
Guest OS就是跑在VM里的操作系统。它可以是Android、Linux、RTOS，甚至Windows IoT。
Guest OS不知道自己是跑在虚拟机里的。它以为自己直接操作硬件。但实际上，所有敏感操作（比如访问中断控制器、操作页表）都会被Hypervisor拦截。
这里有个关键点：半虚拟化。如果Guest OS知道自己被虚拟化了，它可以主动调用Hypervisor提供的接口（比如virtio），性能会更好。MTK的方案里，Android和Linux都做了半虚拟化优化。
1.4 MTK虚拟化方案整体架构
好了，前面铺垫了这么多，咱们来看看MTK在8678上到底怎么搞的。
MTK的虚拟化方案，我给它总结为三个字：分层、隔离、共享。
1.4.1 架构分层
从底层到上层，大概是这样的：
| 层级 | 组件 | 说明 |
|---|---|---|
| EL3 | ATF（ARM Trusted Firmware） | 安全监控，负责启动和切换安全世界 |
| EL2 | Hypervisor（MTK自研） | 核心调度，管理VM生命周期 |
| EL1 | Guest OS（Android/Linux/RTOS） | 跑业务逻辑，不直接操作硬件 |
| EL0 | 用户态应用 | 普通APP |
MTK的Hypervisor跑在EL2，这是ARMv8规定的虚拟化特权级。它负责：
- CPU虚拟化：通过VTIMER和GICv3中断虚拟化。
- 内存虚拟化：通过Stage-2页表，给每个VM独立的物理地址空间。
- 设备虚拟化：通过SMMU和中断重映射，让VM安全访问外设。
1.4.2 隔离机制
隔离是虚拟化的命根子。MTK的方案里，隔离做得相当硬核：
- CPU隔离：每个VM可以绑定固定的物理核心。比如VM0用Core0-1，VM1用Core2-3。互不干扰。
- 内存隔离：Stage-2页表保证VM0访问不了VM1的内存。哪怕VM0的Linux内核崩了，也读不到VM1的Android数据。
- 外设隔离：通过SMMU，每个VM只能访问分配给它的外设。比如摄像头只能给Android用，CAN总线只能给RTOS用。
注意：隔离不是绝对的。共享内存区域（比如用于VM间通信的shm）需要特别小心。我见过一个案例，因为共享内存的权限没配好，导致一个VM的恶意程序把另一个VM的音频数据给篡改了。嗯，这属于严重的安全事故。
1.4.3 共享机制
完全隔离也不行，VM之间总得通信吧？MTK的方案提供了几种共享方式：
- 共享内存（Shm）：用于大数据量传输，比如视频流。通过Hypervisor配置的共享内存区域，两个VM可以直接读写。
- 虚拟网卡（Virtio-net）：用于网络通信。每个VM都有一个虚拟网卡，通过Hypervisor桥接。
- 消息队列（Mbox）：用于控制命令。比如Android发一个“播放音乐”的命令给RTOS。
我建议在实际项目中，优先用共享内存做数据面，用消息队列做控制面。别混在一起，否则调试起来你会疯掉。
1.5 小结
这一章咱们把虚拟化的底子打好了。MTK8678是个好平台，硬件支持到位。虚拟化从大型机走到嵌入式，核心概念就三个：Hypervisor、VM、Guest OS。MTK的方案核心是分层、隔离、共享。
下一章，咱们会深入EL2，手把手搭建第一个Hypervisor环境。到时候你会看到，代码是怎么跑在硬件之上的。
嗯，今天就到这儿。有问题随时问。