GIC Multi-View &Multi-Chip

1. 基本概念

1.1 GIC Multi-View

Multi-View 是 GICv3/v4 规范中内建的访问视图隔离机制。同一套 GIC 硬件，根据访问者的安全状态（Secure/Non-Secure）和异常级别（EL0~EL3），呈现出不同的"中断视图"——每个视图只能看到并操作属于自己 Group 的中断，互不干扰。

核心原理是中断分组（Interrupt Grouping）：

Group 0        → FIQ 触发，Secure EL3 / EL1 处理
Group 1 Secure → IRQ 触发（Secure 侧），Secure EL1 处理
Group 1 NS     → IRQ 触发（NS 侧），Non-Secure EL1/EL2 处理

不同 Group 的中断在 GICD/GICR 中有独立的使能、优先级、pending 寄存器集合，CPU 只能 Acknowledge 自己状态下可见的 Group。

1.3 LPI 与 Group 的强制绑定

LPI（Locality-specific Peripheral Interrupt，INTID ≥ 8192）是 GICv3 引入的消息信号式中断，通过 ITS（Interrupt Translation Service）+ MSI 机制触发。GICv3 规范明确规定：

LPI 只能属于 Group 1 Non-Secure，硬件上不可配置为 Group 0 或 Group 1 Secure。

中断类型        INTID 范围       可用 Group
─────────────────────────────────────────────────────
SGI             0  ~ 15         Group 0 / Group 1S / Group 1NS（可配置）
PPI            16  ~ 31         Group 0 / Group 1S / Group 1NS（可配置）
SPI            32  ~ 1019       Group 0 / Group 1S / Group 1NS（可配置）
LPI          8192  ~            仅 Group 1 NS（硬件固定，不可更改）

影响与限制：

• Secure EL1（TEE / RTOS）和 Secure EL3 无法使用 LPI，也无法通过 ITS 接收 MSI 中断
• PCIe 设备产生的 MSI/MSI-X 经 ITS 翻译后只能路由到 Non-Secure 的 CPU（即运行 Linux / Android 的核）
• 若 Secure 侧 RTOS 需要响应 PCIe 设备，必须通过以下变通方案：
  1. Non-Secure Linux 接收 LPI → 通过共享内存 + SGI 通知 Secure RTOS（软件转发）
  2. 使用 SPI 替代 LPI（需要设备支持传统线中断模式）
  3. EL3（ATF）作为中介拦截并转发（增加 Secure Monitor 调用开销）

这是 Multi-View 在 AMP 场景中最容易踩坑的限制：将 PCIe / NVMe 等仅支持 MSI 的设备分配给 Secure RTOS 时，必须考虑此约束。

1.4 GIC Multi-chip

Multi-chip 是 GICv3/v4 规范中用于跨物理芯片中断互联的扩展机制。每块芯片拥有独立的 GIC 实例（独立 GICD + 独立 GICR），通过芯片间专用信号线（或片间互联总线）将多个 GIC 组成一个逻辑上统一的中断域，使任意芯片上的外设中断可以路由到任意芯片上的 CPU。

┌──────────────────┐     chip-to-chip      ┌──────────────────┐
  │  Chip 0          │◄─────────────────────►│  Chip 1          │
  │  GICD #0         │     物理互联信号线      │  GICD #1         │
  │  GICR × N        │                        │  GICR × N        │
  │  CPU 0 ~ N-1     │                        │  CPU N ~ 2N-1    │
  └──────────────────┘                        └──────────────────┘

---

2. 架构对比

2.1 硬件拓扑

Multi-View（单芯片，一个 GIC）:

  ┌──────────────────────────────────────────────────────┐
  │                     单块 SoC                          │
  │                                                      │
  │   ┌──────────────────────────────────────────────┐   │
  │   │                  GICD（唯一）                  │   │
  │   └───────────┬──────────────────┬───────────────┘   │
  │               │                  │                   │
  │         GICR × 4           GICR × 4                 │
  │        Cluster 0           Cluster 1                 │
  │       CPU 0~3 (NS)        CPU 4~7 (S)               │
  │       Linux               RTOS / TEE                 │
  └──────────────────────────────────────────────────────┘


Multi-chip（多块芯片，多个 GIC）:

  ┌──────────────────┐               ┌──────────────────┐
  │  Chip 0 (SoC #0) │               │  Chip 1 (SoC #1) │
  │  ┌────────────┐  │               │  ┌────────────┐  │
  │  │  GICD #0   │  │◄─────────────►│  │  GICD #1   │  │
  │  └────────────┘  │  chip-to-chip │  └────────────┘  │
  │  GICR × 8        │               │  GICR × 8        │
  │  CPU 0 ~ 7       │               │  CPU 8 ~ 15      │
  │  本地外设 A~F     │               │  本地外设 G~L    │
  └──────────────────┘               └──────────────────┘

2.2 关键参数对比

---

3. Multi-View 深度分析

3.1 视图层次

GICv3 定义了四个访问视图，由硬件根据当前 PE 状态自动切换：

访问者状态                  可见中断范围
─────────────────────────────────────────────────────
Secure EL3 (Monitor)    → Group 0 + Group 1S + Group 1NS（全部）
Secure EL1 (TEE/RTOS)   → Group 0 + Group 1 Secure
Non-Secure EL2 (Hyp)    → Group 1 NS + 虚拟中断控制（GICH）
Non-Secure EL1 (OS)     → Group 1 NS
Non-Secure EL0 (App)    → 不直接访问 GIC

虚拟化扩展在此基础上再加一层：

Hypervisor (EL2)
    ↓ 通过 GICH_LR（List Register）注入虚拟中断
Guest OS (vEL1)
    ↓ 通过 GICV（Virtual CPU Interface）看到虚拟中断
    ↓ 读 GICV_IAR 得到 vINTID，写 GICV_EOIR 完成 EOI

3.2 关键寄存器

3.3 优点

隔离成本极低 不需要任何额外硬件，GICv3 内建支持，配置 GICD_IGROUPR 即可完成隔离，开发成本几乎为零。

安全性有硬件背书 Group 0 的中断在硬件层面对 Non-Secure 世界不可见，Non-Secure 软件无法 Acknowledge 或伪造 Group 0 中断，满足 TrustZone 的安全模型要求。

虚拟化开销小 Hypervisor 通过 List Register 直接注入虚拟中断，Guest OS 通过 GICV 接口响应，整个路径在 GIC 硬件内完成，无需陷入 EL2 处理每一个中断的 Acknowledge/EOI。

统一的中断号空间 所有 CPU 共享同一个 GICD，中断号（INTID）全局唯一，不存在跨域翻译问题，调试和追踪直观。

低延迟 中断从外设到目标 CPU 的路径完全在片内，无跨芯片传输延迟。

3.4 缺点

隔离粒度受限于 Group 数量 GICv3 只有三个 Group，最多支持三个完全隔离的中断域（Group 0、Group 1S、Group 1NS）。如果需要四个或更多完全隔离的 OS 实例，仅靠 Group 无法实现，必须叠加虚拟化（Hypervisor）。

非安全侧无法完全信任安全侧配置 Group 的划分由 Secure 侧（EL3）控制，Non-Secure 侧只能接受分配给自己的中断，无法自主添加。在某些动态场景下（如 Non-Secure 侧热插拔设备），需要与 Secure 侧协商，增加软件复杂度。

所有核共享 GICD 带来竞争 大量核同时配置 GICD 寄存器时，存在总线竞争，需要软件加锁保护，在核数极多（64+）时可能成为瓶颈。

LPI 无法用于 Secure 侧 LPI（INTID ≥ 8192）硬件固定为 Group 1 NS，Secure RTOS / TEE 无法直接使用 MSI 类设备（PCIe NVMe、高速网卡等），必须通过软件转发或改用 SPI 线中断，增加系统设计复杂度。

物理边界限制 严格局限于单个 GIC 管辖范围，跨芯片场景完全无法使用。

3.5 使用案例

---

案例一：TrustZone AMP — 移动 SoC（Linux + OP-TEE）

场景描述

智能手机 SoC，全部 CPU 核运行在同一芯片上，Linux（Android）与 OP-TEE 并行运行，通过 TrustZone 隔离。

软件栈分层

Exception Level    运行软件              中断 Group
─────────────────────────────────────────────────────────
EL3 (Secure)      ATF BL31              管理 Group 0，仲裁 Secure/NS 切换
EL1 (Secure)      OP-TEE OS             Group 1 Secure
EL1 (NS)          Android / Linux       Group 1 NS
EL0 (NS)          App（微信、支付宝等）  不直接访问 GIC

中断分配

Group 0（FIQ，EL3 直接处理或转发给 Secure EL1）:
  INTID 29  → Secure Physical Timer（EL3 心跳）
  INTID 33  → Secure Watchdog（防止 TEE 死锁）

Group 1 Secure（IRQ，OP-TEE 处理）:
  INTID 34  → Crypto Engine（AES/RSA 加速器完成中断）
  INTID 35  → Secure UART（调试口，仅 TEE 可见）
  INTID 36  → TrustZone Memory Controller 违例中断

Group 1 NS（IRQ，Linux 处理）:
  INTID 96  → Ethernet
  INTID 128 → USB
  INTID 160 → Display Controller
  INTID 192 → Camera ISP
  INTID 224 → Audio Codec
  INTID 8192+ → PCIe NVMe（LPI，经 ITS 路由）

关键配置代码（ATF BL31 阶段）

// 配置 Crypto Engine 中断为 Group 1 Secure
// GICD_IGROUPR[1]  bit2 = 0 → not Group 1
// GICD_IGRPMODR[1] bit2 = 1 → Group 1 Secure (配合 bit=0 得到 1S)
GICD_IGROUPR[1]  &= ~(1 << 2);   // INTID=34, bit = 34%32=2
GICD_IGRPMODR[1] |=  (1 << 2);

// 配置以太网中断为 Group 1 NS
// GICD_IGROUPR[3]  bit0 = 1 → Group 1
// GICD_IGRPMODR[3] bit0 = 0 → Group 1 NS
GICD_IGROUPR[3]  |=  (1 << 0);   // INTID=96
GICD_IGRPMODR[3] &= ~(1 << 0);

// 路由 Crypto Engine 中断到 CPU0（OP-TEE 固定在 CPU0）
GICD_IROUTER[34] = 0x0;          // Aff1=0, Aff0=0

隔离效果

• Linux 调用 ICC_IAR1_EL1 只能 Acknowledge Group 1 NS 中断，硬件拒绝其访问 Group 1S
• OP-TEE 的 Crypto Engine 中断不会出现在 Linux 的 /proc/interrupts 中
• 即使 Linux 被攻击者控制，也无法拦截或伪造 Secure 侧中断

---

案例二：TrustZone AMP — 工业 SoC（实时 RTOS + Linux）

场景描述

工业机器人控制器，同一 SoC 上 Cortex-A 核分为两组：一组跑实时 RTOS 控制电机，一组跑 Linux 做 HMI 和网络通信。RTOS 需要硬实时保证（中断延迟 < 10 µs）。

拓扑与分配

┌──────────────────────────────────────────────────────────┐
  │                    工业 SoC                               │
  │                                                          │
  │   Cluster 0 (Cortex-A55 × 4)    Cluster 1 (Cortex-R × 2)│
  │   Linux HMI / 网络通信           实时电机控制 RTOS        │
  │   Group 1 NS                     Group 0                 │
  │                                                          │
  │   GICD_IROUTER[PWM]  = Aff1=1, Aff0=0  → RTOS CPU      │
  │   GICD_IROUTER[ETH]  = Aff1=0, Aff0=0  → Linux CPU     │
  └──────────────────────────────────────────────────────────┘

中断分配：
  Group 0  → PWM INTID 33（电机 PWM 周期，500 µs 触发一次）
             ADC  INTID 34（电流采样，1 kHz）
             ENC  INTID 35（编码器脉冲，高频）
             WDT  INTID 36（RTOS 看门狗）

  Group 1NS → ETH  INTID 96（以太网，Linux 处理）
              CAN  INTID 97（CAN 总线，Linux 处理）
              UART INTID 98（调试串口）

实时性保障机制

1. Group 0 中断以 FIQ 形式到达 RTOS，绕过 Linux 的中断处理路径
2. ATF 配置 SCR_EL3.FIQ = 1，FIQ 路由到 EL3，再由 ATF 转发给 Secure EL1
3. Linux 的软中断风暴（ETH 高负载）不影响 Group 0 FIQ 的响应时间
4. RTOS 的 PWM 中断优先级配置为最高（GICD_IPRIORITYR = 0x00）

注意事项

• PWM / ADC 等设备只能用传统线中断（SPI），不能用 MSI，因为 LPI 无法配置为 Group 0
• RTOS 与 Linux 之间通信通过共享内存 + SGI（SGI 可配置 Group，Secure RTOS 发 Group 0 SGI 通知 Linux）

---

案例三：Hypervisor — Type-1 虚拟机（KVM / Xen）

场景描述

服务器 SoC，EL2 运行 KVM 或 Xen，上层托管多个 Guest VM，每个 VM 看到完全隔离的虚拟中断视图。

GICv3 虚拟化硬件支持

物理层（Hypervisor 视角）:
  GICD    → Hypervisor 直接配置，控制物理中断路由
  GICR    → 每个物理 CPU 有独立 GICR
  ICC_*   → Hypervisor 用系统寄存器访问物理 CPU Interface

虚拟层（Guest VM 视角）:
  GICH_LR[0~15]  → Hypervisor 填入虚拟中断，注入 Guest
  GICV           → Guest 通过 MMIO 访问虚拟 CPU Interface（低性能路径）
  ICV_*          → GICv3：Guest 通过系统寄存器访问（高性能路径，需 EL2 配置）

中断注入流程（物理 SPI → Guest VM）

① 外设产生 SPI（如网卡 INTID 96）
② GICD 路由到物理 CPU3（Hypervisor 在此核调度 VM1）
③ CPU3 陷入 EL2，Hypervisor 的中断处理程序执行
④ Hypervisor 查询设备分配表：INTID 96 分配给 VM1
⑤ Hypervisor 写 GICH_LR（List Register）：
     GICH_LR.vINTID = 100        ← VM1 内的虚拟中断号
     GICH_LR.pINTID = 96         ← 对应物理中断号（用于硬件 deactivate）
     GICH_LR.State  = Pending
     GICH_LR.HW    = 1           ← 硬件链接，EOI 时自动 deactivate 物理中断
⑥ Hypervisor 切换回 VM1（eret 到 EL1）
⑦ GIC 硬件检测到 GICH_LR 有 Pending 虚拟中断，向 VM1 发出 vIRQ
⑧ VM1 Guest OS 读 ICV_IAR1_EL1 得到 vINTID=100，执行中断处理
⑨ VM1 写 ICV_EOIR1_EL1=100，GIC 自动 deactivate 物理 INTID 96

多 VM 中断隔离

物理中断分配表（Hypervisor 维护）:
  INTID 96  → VM0（虚拟 INTID 32）   ← 网卡直通
  INTID 97  → VM1（虚拟 INTID 33）   ← 存储控制器直通
  INTID 98  → Hypervisor 自用        ← 调度定时器
  INTID 99  → VM0 + VM1 共享        ← 需 Hypervisor 软件仲裁

VM0 写 ICV_EOIR1_EL1 时只能 deactivate 分配给它的虚拟中断，
无法触碰 VM1 的中断状态，隔离由 GIC 硬件保证。

List Register 容量与溢出处理

GICv3 规定每个物理 CPU 有 16 个 GICH_LR（LR0~LR15）。
当 VM 的待注入虚拟中断超过 16 个时：
  → GICH_HCR.UIE（Underflow IRQ Enable）触发 maintenance interrupt
  → Hypervisor 收到 maintenance interrupt，重新填充 LR
  → 这是 Hypervisor 中断处理的重要路径，高负载下需优化 LR 填充策略

SGI 虚拟化（VM 内核间通信）

VM1 的 CPU0 发 SGI 给 VM1 的 CPU1：
  VM 写 ICV_SGI1R_EL1（虚拟 SGI 寄存器）
  → GIC 硬件拦截，产生 maintenance interrupt 通知 Hypervisor
  → Hypervisor 查询目标：VM1.CPU1 当前在物理 CPU5 上运行
  → Hypervisor 向物理 CPU5 的 GICH_LR 注入虚拟 SGI
  → VM1.CPU1 收到虚拟 SGI

---

案例四：Hypervisor — 混合实时虚拟化（Jailhouse / ACRN）

场景描述

车载或工业场景，同一 SoC 上静态分区：部分核分配给实时域（裸机或 RTOS），其余核分配给 Linux 通用域，两个域之间严格隔离，延迟确定性优先于灵活性。

Jailhouse 静态分区模型

┌──────────────────────────────────────────────────────────┐
  │                      SoC（8 核）                         │
  │                                                          │
  │  Root Cell（Linux）          Non-root Cell（RTOS）        │
  │  CPU 0~5                     CPU 6~7                     │
  │  Group 1 NS                  Group 0 / Group 1S          │
  │                                                          │
  │  GICD_IROUTER[ETH]  → CPU0   GICD_IROUTER[PWM] → CPU6  │
  │                                                          │
  │  Root Cell 可访问全部 GICD    Non-root Cell 只能访问      │
  │  寄存器（Jailhouse 管控）     GICR 和自己的 ICC 寄存器    │
  └──────────────────────────────────────────────────────────┘

与 KVM 虚拟化的对比

跨 Cell 通信（中断通道）

RTOS Cell 完成计算 → 需通知 Linux Cell：
  方式一：RTOS 触发 SGI → Jailhouse 拦截 → 转发给 Linux 对应 CPU
  方式二：共享内存 doorbell，RTOS 写内存 → Linux 轮询（无中断开销）
  方式三：Jailhouse 虚拟 PPI，RTOS 写特定地址 → Hypervisor 注入 Linux 虚拟中断

---

4. Multi-chip 深度分析

4.1 互联机制

GICv3 Multi-chip 通过两种方式实现跨芯片中断路由：

方式一：专用 chip-to-chip 信号线（GICv3 规范定义）

Chip 0 GICD                    Chip 1 GICD
    │                               │
    ├── GICMP (GIC Message Port) ──►├── 接收跨片中断请求
    │◄─ GICMP ──────────────────────┤── 发送跨片中断请求

每个 GICD 维护一张路由表，知道哪些 Affinity（Aff3）对应哪个物理芯片，跨片请求通过 GICMP 转发。

方式二：基于 ITS（Interrupt Translation Service）的 LPI 路由

外设 → MSI 写 ITS → ITS 查询 ITT（Interrupt Translation Table）
    → 得到目标 CPU 的 Redistributor 地址（可跨芯片）
    → 通过片间互联将 LPI 发到目标 Chip 的 GICR

这种方式依赖片间互联总线支持内存访问，适合 PCIe/CCIX 等标准互联。

4.2 Aff3 与路由表

GICD_IROUTER[intid]:
  bits[39:32] = Aff3  → 目标芯片编号
  bits[23:16] = Aff2  → 目标 Socket
  bits[15: 8] = Aff1  → 目标 Cluster
  bits[ 7: 0] = Aff0  → 目标 Core

每个 GICD 还需配置：
  GICD_CHIPSR  → 本芯片的 Aff3 编号
  GICD_DCHIPR  → 指向其他芯片 GICD 的路由入口地址（实现相关）

4.3 优点

突破单芯片核数上限 单个 GICv3 理论上支持 2^32 个 PE，但受限于 GICD 总线带宽和芯片面积，实际单芯片核数有上限。Multi-chip 允许将多块芯片的 CPU 组成统一中断域，线性扩展核数，适合构建大规模 SMP 系统。

强物理隔离 每块芯片有独立 GICD，一块芯片的 GICD 故障不会直接导致另一块芯片的中断控制器崩溃，具备一定的故障隔离能力（取决于互联设计）。

本地中断低延迟 每块芯片的本地外设中断路由到本地 CPU 时，路径与单芯片完全一致，不经过片间互联，无额外延迟。

支持超大规模 NUMA 系统 Aff3 + Aff2 + Aff1 + Aff0 四级编址，理论支持 256 × 256 × 256 × 256 个 PE，为构建超大规模 ARM 服务器提供寻址空间。

4.4 缺点

需要额外硬件支持 芯片间必须有专用的物理信号线或支持 GIC 互联协议的总线，不是所有 SoC 都实现了这一功能，通用性差。

跨片中断延迟高 中断请求需要经过片间互联传输，相比片内路由增加数十到数百纳秒的延迟，对实时性要求极高的场景不友好。

软件复杂度大幅提升

• 启动时需要枚举所有芯片的 GICR，数量可能达到数百个
• GICD_IROUTER 配置必须包含正确的 Aff3
• SGI 跨片广播需要额外机制（片间 SGI 不能直接用 ICC_SGI1R_EL1，需通过 GICD 转发）
• 电源管理复杂（某块芯片下电时，路由到其 CPU 的中断需要重新配置）

调试困难 中断路径跨越物理芯片边界，示波器或逻辑分析仪需要同时覆盖多块板，中断丢失、延迟抖动的根因定位难度大。

互操作性依赖厂商实现 GICv3 规范定义了 Multi-chip 的框架，但具体的片间信号协议和寄存器扩展由芯片厂商自行实现，不同厂商的 Multi-chip GIC 之间不能互联。

4.5 使用案例

案例一：ARM 多 Die 服务器（如 Ampere Altra Max）

Die 0（128 核）              Die 1（128 核）
  GICD #0                    GICD #1
  Aff3 = 0                   Aff3 = 1
  CPU 0~127                  CPU 128~255
  本地 PCIe / NVMe           本地 PCIe / NVMe

跨 Die 中断：
  Die 0 的 NIC 产生中断 → 需要送到 Die 1 的 CPU 200
  → GICD #0 查路由表：Aff3=1 → 通过 GICMP 转发到 GICD #1
  → GICD #1 路由到 CPU 200 的 GICR

OS（Linux）通过 ACPI/MADT 表获取所有 GICR 基地址和对应的 MPIDR，统一管理。

案例二：多 SoC 工业控制系统

Board 0（主控 SoC）          Board 1（DSP/加速器 SoC）
  Cortex-A × 8               专用计算核 × 16
  GICD #0                    GICD #1
  运行 Linux + 实时任务        运行专用固件

互联：高速串行总线（支持 GIC GICMP 协议）

使用场景：
  Board 1 的计算完成中断 → 路由到 Board 0 的 CPU 3
  Board 0 的任务调度 SGI → 广播到 Board 1 的所有核

案例三：高可用双芯片冗余系统

Active Chip                  Standby Chip
  GICD #0 (Aff3=0)           GICD #1 (Aff3=1)
  处理所有业务中断             监控 Active Chip 心跳

故障切换：
  Active Chip 故障 → 看门狗中断通过片间互联触发 Standby Chip
  → Standby 接管中断路由，重配 GICD_IROUTER，接管业务

---

5. 综合对比总结

5.1 优缺点汇总

5.2 选型决策树

系统是否跨多块物理芯片？
│
├── 否（单芯片）→ 只能用 Multi-View
│     │
│     ├── 需要安全隔离（TrustZone）？→ Group 0 / Group 1S / Group 1NS 分配
│     ├── 需要多 OS 隔离（AMP）？   → Group 分配 + Affinity 路由
│     └── 需要虚拟机隔离？          → Multi-View + Hypervisor（GICH/GICV）
│
└── 是（多芯片）→ 必须用 Multi-chip
      │
      ├── 各芯片内部仍需 OS 隔离？  → Multi-chip + Multi-View 叠加使用
      └── 纯计算扩展，单一 OS？    → Multi-chip，Linux 统一管理所有 CPU

5.3 两者叠加使用

Multi-View 和 Multi-chip 并不互斥，大型系统中经常叠加：

整体系统：Multi-chip（多块服务器芯片，统一中断域）
每块芯片内部：Multi-View（Hypervisor + 多个 Guest VM）

Chip 0:
  GICD #0 (Aff3=0)
  ├── EL2 Hypervisor
  │   ├── VM0: Linux（Group 1 NS + GICH 虚拟中断）
  │   └── VM1: RTOS（Group 0 + GICH 虚拟中断）
  └── 跨片中断接收（来自 Chip 1 的 GICMP）

Chip 1:
  GICD #1 (Aff3=1)
  └── 同上结构

---

6. 关键结论

1. Multi-View 是单芯片内的软件隔离手段，零硬件成本，AMP / TrustZone / 虚拟化场景首选。
2. Multi-chip 是多芯片的硬件互联方案，用于突破单芯片规模上限，代价是硬件成本和软件复杂度双双提升。
3. AMP 系统不需要 Multi-chip。只要所有核在同一芯片上共享同一个 GIC，Multi-View 的 Group 隔离完全满足需求，且更简单、延迟更低。
4. Multi-View 的边界是 GIC，不是 Cluster，多少个 Cluster 都不影响 Multi-View 的工作。
5. LPI 只能属于 Group 1 NS，这是 Multi-View 在 AMP 场景中最容易忽视的硬性约束——PCIe / MSI 类设备无法分配给 Secure RTOS，设计时必须提前规划。
6. 两者可以叠加，大规模系统中每块芯片内部使用 Multi-View 做隔离，芯片之间使用 Multi-chip 做互联，各司其职。