arceos-hypervisor
Replies: 6 comments 16 replies
-
timer 接口与定义data structurepub struct VmmTimerEvent {
// task：注册 timerirq 的 task
task: CurrentTask,
// 当时钟到期时，触发的回调函数
timer_callback: Box<dyn FnOnce(TimeValue) + Send + 'static>,
}
#[percpu::def_percpu]
static TIMER_LIST: LazyInit<SpinNoIrq<TimerList<VmmTimerEvent>>> = LazyInit::new();TimerList：一个小根堆，用于维护多个定时器及其回调函数。 TimerList 相关接口
timer 相关接口// deadline: ns，需要在各架构的 vcpu 实现中转成统一单位
// 注册一个时钟中断到 TIMER_LIST 中
pub fn register_timer(deadline: u64, handler: VmmTimerEvent) {
let timer_list = unsafe { TIMER_LIST.current_ref_mut_raw() };
let mut timers = timer_list.lock();
timers.set(TimeValue::from_nanos(deadline as u64), handler);
}
// 将 TIMER_LIST 中所有满足条件的中断全部删除
pub fn cancel_timer<F>(condition: F)
where
F: Fn(&VmmTimerEvent) -> bool, {
let timer_list = unsafe { TIMER_LIST.current_ref_mut_raw() };
let mut timers = timer_list.lock();
timers.cancel(condition);
}
// 触发 TIMER_LIST 中全部到期的时钟中断
pub fn check_events() {
loop {
let now = axhal::time::wall_time();
let timer_list = unsafe { TIMER_LIST.current_ref_mut_raw() };
let event = timer_list.lock().expire_one(now);
if let Some((_deadline, event)) = event {
// 处理时间中断
......
} else {
break;
}
}
}
// 设置下一次时钟中断到期的时间
pub fn scheduler_next_event() {
// info!("set deadline!!!");
let now_ns = axhal::time::monotonic_time_nanos();
let deadline = now_ns + PERIODIC_INTERVAL_NANOS;
axhal::time::set_oneshot_timer(deadline);
}
// 初始化时钟中断，需要重新注册 arceos 时钟中断
pub fn init() {
let timer_list = unsafe { TIMER_LIST.current_ref_mut_raw() };
timer_list.init_once(SpinNoIrq::new(TimerList::new()));
axhal::irq::register_handler(axhal::time::TIMER_IRQ_NUM, || {
check_events();
scheduler_next_event();
});
}situationcase1timer到期时，vcpu未运行（可能与timer_list在同一核也可能在不同核）。 调用 callback 处理。 case2timer到期时，vcpu 和timer_list在同一核。 调用 callback 处理。 case3timer到期时，vcpu正在运行，和timer_list在不同核。
case4arceos时钟中断。（调度） timer 处理的全流程
其他 timer 中断处理的接口arch_vcpu
axvcpu AxVCpuExitReason 里增加 ： /// Register a timer
/// Because vmm is needed to register clock interrupts.
SetTimer { time: u64, callback: fn(TimeValue) },
/// A clock interrupt occurs
TimerIrq,
/// ipi
IPI,vcpu 增加接口 // 获取vcpu 正在运行的 cpu 的 id
pub fn get_cpu_id(self) -> i32; umhv 添加 timers.rs 用来处理 timer 相关接口（见上） 添加 IPI 处理接口 // vcpu 是目标 vcpu，irq 是 TimerIrq
pub fn inject_irq(vcpu, callback, irq) {
let to = vcpu.get_cpu_id();
if to < 0 || to == this_cpu_id() {
callback();
} else {
// 给 to 发送附带参数的 IPI
send_ipi(to, vcpu, callback, irq);
}
} |
Beta Was this translation helpful? Give feedback.
-
|
当timer到期时，vcpu未运行，这个时候如果其他guest正在处理timer中断(active到panding中间)，直接callback貌似不太合理吧？ |
Beta Was this translation helpful? Give feedback.
-
|
callback 就是为了 当timer到期时，vcpu未运行 这种情况设计的。我的想法是第一，即便这个 vcpu 正在这个核运行，但是后面处理 timerlist 可能会触发调度导致 vcpu 变成不可运行的状态，所以这种情况和 当timer到期时，vcpu未运行 算作一种处理，就是 callback。第二，timer 中断放到 umhv 处理，此时之前在运行 vcpu 的状态应该不是运行状态了。所以理论上来说case 2是不存在的，所以 callback 就是为了 当timer到期时，vcpu未运行 这种情况设计的。 |
Beta Was this translation helpful? Give feedback.
-
ARM 定时器中断通用定时器(Generic Timer)通用计时器为ARM的处理器核提供了一个标准化的计时器框架。通用计时器包含一个系统计数器（System Counter）和每个处理器核自己的计时器（per-core timer），如下图。图中的PE（Processor Element）代表处理器核。 系统计数器需要保证在芯片上电启动后一直保持工作，且以固定的时钟频率单调递增计数。系统计数器的数值需要广播给所有的处理器。在多核处理器架构中，即使某些处理器核出于某些原因（节省功耗，生成故障等等）关闭电源，系统计数器仍能为处于工作状态的处理器核提供计数值。 ARM建议系统计数器是56-64bit宽度，工作频率在1-50MHz。我们以最小宽度56bit和最高速度50MHz来计算，计数器溢出需要大概 $$ \frac{2^{56}}{5010^{6}606024*365} $$ ，约为45年。此处只是给出大概的计算，具体的计数器设计要根据实际需求确定。 不知道大家看到这里发现没有，系统计数器只是单调的递增，并不能反映真实物理世界的时间（年，月，日，时，分，秒）。也就是说，SoC还需要板级提供一个RTC（Real-Time Clock），以供给真实时间。 每个处理器有一组计时器。这些计时器本质上是比较器，软件可以设置这些处理器本地计时器的数值，并且与系统计数器广播来的值作比较。当计满后，触发中断（Interrupt）或者事件（Event）。 ARMv8-A中的处理器计时器如下表： 在实际硬件设计中，如何实现这种跨时钟域的数据传输？首先，系统计数器需要传输给处理器核，系统计数器工作在低频下（MHz），而处理器工作在高频下（GHz），如何在两个时钟频率下传输一组数值？这个问题可以通过二进制和格雷码转换来解决。系统计数器的数值转换成格雷码，以格雷码的形式在芯片中传播；在处理器端，先做跨时钟域采样，这样会保证采样不会采错，然后格雷码转换成二进制。 多核处理器芯片中如何保证时钟同步？系统计数器的值要传播给所有的处理器。这时，需要一定的机制保证该值同一时刻（此处不是绝对意义的分毫不差）到达每个处理器端。否则的话，可能会引发错误。例如，假设两个处理器A核B，处理器A端的系统计数器值更新快于处理器B端。处理器A以接收到的系统计数器值为时间戳，发送一个消息给处理器B；处理器B接收到消息后，看到的本地系统计数值如果早于消息中的时间戳，那就肯定不对了（不能接收来自未来的消息吧）。我在ARM的文档中没有找到ARM有什么推荐方案，个人感觉可以通过格雷码打多拍的方式在整个SoC中传播。这样可以保证从系统计数器传播到每个处理器入口端的延时一样，至于每个处理器内部跨时钟域转换造成的偏差，可以认为是系统计数器时钟的抖动（jitter），忽略不计。 多芯片时钟同步第三个问题，是多芯片间的同步问题。一个SMP可能由多个处理器芯片组成，每个处理器芯片有自己的系统计数器。但是SMP要求多芯片内的所有处理器时间保持一致（类似单芯片中的多核间需要一致）。ARM在其参考设计中提供了一个解决方案，使用两个芯片管脚SYNCREQ和SYNCACK实现一组握手协议。芯片间的同步通过这两个专用接口和CCIX消息来完成。 在以下情况下，通过CCIX将消息写入memory-mapped寄存器：
每个PE实现的通用定时器组件每个PE都包含两个定时器，一个是物理定时器(Physical Timer)，另一个是虚拟定时器(Virtual Timer)。 物理定时器(Physical Timer)该物理定时器(Physical Timer)包含系统计数器(System Counter)的计数值，当实现了FEAT_ECV时，CNTPOFF_EL2寄存器保存了可选择设置的物理偏移量。
虚拟定时器(Virtual Timer)虚拟计数器等于物理计数器的值减去64 bits 的虚拟偏移量。CNTVOFF_EL2寄存器包含虚拟偏移量。CNTVCT_EL0寄存器保存着当前的虚拟计数器值。但是注意虚拟计数器和物理计数器一样，读取指令可以被乱序执行，需要使用内存屏障指令保证按序执行。 Timers每个实现的定时器的输出：
每一个定时器： 既可以作为一个 64 bits 的 CompareValue 来呈现，也可以作为 TimerValue 的形式呈现。不同点在于 CompareValue 是一个 64 位无符号的计数值，而 TimerValue 是一个 32 位有符号，并且是以倒计时的方式进行计数。除此之外，每一个定时器还有一个 32-bit 的控制寄存器。
CV 和 TV 的区别
寄存器映射
定时器中断可以将计时器配置为生成中断。来自某个PE定时器器的中断只能传递到该PE。这意味着一个PE的定时器器不能用来生成针对另一个核心的定时器。通过 CTL 寄存器控制中断的生成，使用以下字段: 中断的生成由 CTL 寄存器控制，使用以下字段：
要生成中断，软件必须将 ENABLE 设置为 1 并清除 IMASK。当定时器触发（CVAL <= System Count）时，向中断控制器发出中断信号。在 Armv8-A 系统中，中断控制器通常是通用中断控制器（GIC）。 每个定时器使用的中断 ID（INTID）由服务器基础体系结构（SBSA）定义，如下所示： 注意: 这些 INTID 在私有外围中断(PPI)范围内。这些 INTID 对于特定的PE，这意味着每个核心将其 EL1物理计时器视为 INTID 30。 定时器中断虚拟化在arm平台上的定时器虚拟化相对简单，因为构架强制Generic Timer必须实现，它足够操作系统使用的timekeeping 的需求。KVM使用类似bhyvearm64的方式：virtual timer给虚拟机用，需要注意的是timer产生的中断还是需要hypervisor注入，Physical timer由软件模拟，因为它被host使用了。 A. Generic TimerArmv8构架提供的定时器叫做Generic Timer. 实现上实际包括至少两个不同的timer, 最多到７个。一个系统可以有一个secure physical timer, 一个non secure physical timer, 通常简称为physical timer, 一个 virtual timer, physical和virtual non-secure EL2 timers, physical和virtual secure EL2 timers. 为虚拟化目的，我们聚焦在一般操作系统使用的timer上，也就是physical timer (它计数逝去的真实时间)和virtual timer（它计数带固定偏移的逝去时间）。
B. Virtual timer虚拟化Timer中断是极度时间敏感的。Timer中断以规律性的间隔到来（FreeBSD kernel配置为每１ms一个中断），因为它们这么频繁，因此花太多的时间服务这个中断是极不可取的。这对虚拟中断来说也是适用的：hypervisor在模拟timer上花的时间越少，下一个中断到来前，虚拟机可以利用的CPU时间越多。 中断天然地是异步的；它们可能在任何时候到来，不过处理器在执行什么程序。这也适用于virtual timer中断：一个虚拟timer中断可以在另一个host程序而不是在编程这个timer的虚拟机运行在CPU上时到来。Virtual Timer需要一个机制，在触发中断之前辨别是否是这个timer的虚拟机。 物理世界的时间（墙上时间）4ms里，每个vCPU各运行了2ms。如果我们设置vCPU0的比较器在T=0之后的3ms产生一个中断，那么你希望实际在哪个墙上时间点产生中断呢？ 是vCPU0的虚拟时间的2ms，也就是墙上时间3ms那个点还是 vCPU0虚拟时间3ms的那个点？ 在Arm体系结构中同时支持上述两种设置，这取决于你使用何种虚拟化方案。让我们看看这是如何实现的。 运行在vCPU上的软件可以访问如下两种时钟
EL1物理时钟会与系统计数器(System Conter)模块直接比较，使用的是绝对的墙上时间。而EL1虚拟时钟与虚拟计数器比较。虚拟计数器是在物理计数器的基础上减去一个偏移。 Hypervisor负责为当前调度运行的vCPU指定对应的偏移寄存器。这种方式使得虚拟时间只会覆盖vCPU实际运行的那部分时间。 在一个6ms的时段里，每个vCPU分别运行了3ms。Hypervisor可以使用偏移寄存器来将vCPU的时间调整为其实际运行的时间。 |
Beta Was this translation helpful? Give feedback.
-
待解决的问题如果每个 vCPU 的 offset 都不一致，如何保证VM获取到准确时间，还有同步该VM下的所有vCPU时间？假设能够同步所有时间，当配置一个1000ms的中断，但是该VM下的vCPU实际只运行了500ms，这个时候应不应该按时注入中断？如果按VM的实际运行时间配置中断，那么这个中断该如何计算？ |
Beta Was this translation helpful? Give feedback.
-
串口中断管理在Rust-Shyper中，物理串口是默认分配给第一个管理VM，其他VM的串口挂载到第一个VM下，我们是不是可以使用toml文件来配置将串口中断分配给哪个VM，然后其他VM的串口虚拟到统一的VM中。 |
Beta Was this translation helpful? Give feedback.
-
虚拟中断控制器 接口与定义structure由于结构上的差异，各个架构的中断控制器可能不会共用数据结构，而是编写不同的struct，实现同一个trait。 如果需要的话，中断控制器连接中断源和目标，以下的结构应该是相似的： // 中断源相关
struct Source {
// 中断源的优先级
priority: u32,
// 中断源的等待处理标识
pending: bool,
}
// 目标（核心）相关
struct Target {
// 目标门限，当中断源优先级超过此门限时才有效
threshold: u32,
// 此目标对于每个中断源的使能
enable: [bool; SOURCE_NUM],
// 存放最优中断源
claim: u32,
}
interfacebasic基础接口。其中关于数据类型，发送中断信号的接口，是否定义claim/complete，以及不同数据长度的读写，有多种方案，需要做具体讨论。 trait InterruptController {
// 为设备提供发送中断信号的接口，包括连接哪个中断源（待定），和触发方式（电平/边缘）
fn send_irq(source_id: u32, level: bool);
// 写入，第一种实现
fn write_u32(addr: usize, val: u32);
fn write_u16(addr: usize, val: u16);
fn write_u8(addr: usize, val: u8);
...
// 读取，第一种实现
fn read_u32(addr: usize) -> u32;
fn read_u16(addr: usize) -> u16;
fn read_u8(addr: usize) -> u8;
...
// Claim过程，查看当前的最优中断源，可能会在read中使用而不需要对外暴露
fn claim() -> u32;
// Complete过程，告知中断控制器处理完成，可能会在write中使用而不需要对外暴露
fn complete(val: u32);
// get/set各种属性，可能并不需要对外暴露
// fn set_priority(source_id: u32, priority: u32);
// fn get_priority(source_id: u32) -> u32;
// fn set_enable(target_id: u32, enable: bool);
// fn get_enable(target_id: u32) -> bool;
...
}
读写实现：数据长度作为参数数据长度作为参数，使用最大变量（如u64）作为数据容器，在不同分支中做截断/扩展。 // 读取，第二种实现
fn read(addr: usize, len: usize) -> u64 {
match len {
8 => {
let res: u8 = ...;
return res as u64
}
16 => {
let res: u16 = ...;
return res as u64
}
32 => {...}
...
}
}
// 写入，第二种实现
fn write(addr: usize, val: u64, len: usize) -> u64 {
match len {
8 => {
let data: u8 = val as u8;
...
}
16 => {
let data: u16 = val as u16;
...
}
32 => {...}
...
}
}读写实现：泛型使用泛型接口，并定义一个 trait InterruptController {
fn send_irq(source_id: u32, level: bool);
// 泛型的写接口
fn write<T>(&self, addr: usize, val: T)
where
Self: WriteRead<T>,
{
Self::write_impl(addr, val);
}
// 泛型的读接口
fn read<T>(&self, addr: usize) -> T
where
Self: WriteRead<T>,
{
Self::read_impl(addr)
}
}
trait WriteRead<T> {
fn write_impl(addr: usize, val: T);
fn read_impl(addr: usize) -> T;
}例子： // 自定义控制器
pub struct myic {
base: u64,
size: u32,
data: [u32; 10]
}
// 控制器自有方法
impl myic {
pub fn new(base: u64, size: u32) -> Self {
myic{
base,
size,
data: [0; 10],
}
}
}
// 实现接口
impl InterruptController for myic {
fn send_irq(&self, source_id: u32, level: bool) {
println!("myic send irq");
}
...
}
// 实现对u8的读写
impl WriteRead<u8> for myic{
fn read_impl(addr: usize) -> u8 {
println!("myic read u8");
8
}
fn write_impl(addr: usize, val: u8) {
println!("myic write u8");
}
}
// 实现对u32的读写
impl WriteRead<u32> for myic {
fn read_impl(addr: usize) -> u32 {
println!("myic read u32");
32
}
fn write_impl(addr: usize, val: u32) {
println!("myic write u32");
}
}
// main.rs
fn main() {
let ic = myic;
ic.send_irq(1, true); // myic send irq
ic.write(0x100, 5 as u32); // myic write u32
ic.write::<u8>(0x100, 4); // myic write u8
ic.read::<u8>(0x100); // myic read u8
ic.read::<u32>(0x100); // myic read u32
} |
Beta Was this translation helpful? Give feedback.
-
中断设备的读写使用现有的BaseDeviceOps来进行操作 pub trait BaseDeviceOps {
/// Returns the type of the emulated device.
fn emu_type(&self) -> EmuDeviceType;
/// Returns the address range of the emulated device.
fn address_range(&self) -> AddrRange<GuestPhysAddr>;
/// Handles a read operation on the emulated device.
fn handle_read(&self, addr: GuestPhysAddr, width: usize, vcpu: &dyn VCpuIf) -> AxResult<usize>;
/// Handles a write operation on the emulated device.
fn handle_write(&self, addr: GuestPhysAddr, width: usize, val: usize, vcpu: &dyn VCpuIf);
}每个架构的中断控制器都impl这个BaseDeviceOps，传入vcpu作为判断中断是由哪个vcpu发起中断。 中断源部分关于中断源可能需要修改，将pending改为status: u8，因为中断不止一个状态，可能存在多种更为复杂的状态。 |
Beta Was this translation helpful? Give feedback.
-
关于“中断设备的读写”这里的意思是，中断控制器和其他设备相似的部分由 如果是这样，我认为是更好的。 然后关于“传入vcpu作为判断中断是由哪个vcpu发起中断”，由于PLIC只涉及外部设备中断，所以暂不涉及这一问题。我想确认一下，其他架构，比如arm，会有“通过mmio访问中断控制器向其他cpu发起中断”的情况是吗？
关于“中断源部分”pending由于我不清楚其他中断控制器，因此我是基于riscv PLIC进行的初步设计。对于PLIC来说，pending是一个物理结构，中断源发出的信号会锁存在这个结构里，表示“此中断源有待处理的信号”；pending会在claim后被清除，此后对应的中断源不再参与仲裁。它被按bit编入一个4B的mmio寄存器，此寄存器可以被只读访问。 于是以PLIC为例，我加入了 然后关于状态，riscv PLIC的手册中不涉及状态的管理，也没有给出控制器的状态机定义。若其他架构需要维护，或许可以加入一个 目标我的想法是，Source代表控制器的“入口”，“入口”方连接设备。Target表示的是控制器的“出口”，“出口”方连接cpu。 我在实现vPLIC时，使用Target的方式类似： 不过这基于的假设是，中断控制器Target和Cpu的连接具有某种映射关系，可以从Target推出cpu_id。例如中断控制器的Target0会连接Cpu0，Target1会连接Cpu1等。手册很可能并没有规定连接方式这一点，因此假设是错误的。 这确实是一个需要增加的成员，Target中应该有 另外，我不太明白“如果没有指定，那么默认处理该中断的vCPU是哪个”的情况。在我基于PLIC的理解中，cpu是被硬连线在控制器的“出口”（Target）的，若存在一个“出口”的导线不与cpu连接（即没有指定），那么这个导线上的信号自然不会有cpu响应。
|
Beta Was this translation helpful? Give feedback.
-
更新的Timer设计文档
Guest 对 Timer 的访问移除 TimerList
Timer 对 Guest 的通知
在向 |
Beta Was this translation helpful? Give feedback.
-
@hky1999 @guoweikang 大佬们确认一下这个可行吗？我不太确定。 |
Beta Was this translation helpful? Give feedback.
-
|
是不是得确定一个最小的timer设定值，比如1ms之类的。 |
Beta Was this translation helpful? Give feedback.
-
另外，这里是不是可以直接复用现有的 |
Beta Was this translation helpful? Give feedback.
-
Please check this PR arceos-hypervisor/riscv_vcpu#10, where I introduced |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
如果不考虑
关于第1个需求： 保证 GUEST VM 的 不同
关于第2个需求： 能够支持
|
Beta Was this translation helpful? Give feedback.
-
about timer, can we just refer the "vtimer" design in shyper, like this https://github.com/search?q=repo%3Ashyper-org%2Frtshyper%20vtimer&type=code, which can be implemented in |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
一、GICv2介绍
通过上图可以确定，GIC 主要包含 3 部分：Distributor、CPU interfaces 和 Virtual CPU interfaces。Virtual CPU interfaces 包含 Virtual interface control 和 Virtual CPU interface。
中断进入 distributor，然后分发到 CPU interface
某个 CPU 触发中断后，读 GICC_IAR 拿到中断信息，处理完后写 GICC_EOIR 和 GICC_DIR（如果 GICC_CTLR.EOImodeNS 是 0，则 EOI 的同时也会 DI）
GICD、GICC 寄存器都是 MMIO 的，device tree 中会给出物理地址
中断类型
1. 软件生成中断（Software Generated Interrupts, SGI）
2. 私有外设中断（Private Peripheral Interrupts, PPI）
3. 共享外设中断（Shared Peripheral Interrupts, SPI）
中断号范围：32 到 1019（共 988 个中断号）
用途：用于处理系统中共享的外设中断，例如来自外部设备、网络接口、存储设备等的中断。
特点：这些中断是所有核心共享的，可以由任何一个核心处理，通常通过中断亲和性（affinity）来决定哪个核心处理该中断。
SPI默认发送vcpu 0上，同样将中断信号放到vcpu的ap_list字段排队，等待vcpu处理。
Distributor 作用
Distributor 主要作用为检测中断源、控制中断源行为和将中断源分发到指定 CPU 接口上（针对每个 CPU 将优先级最高的中断转发到该接口上）。
Distributor 对中断的控制包括：
全局启用中断转发到 CPU 接口
开启或关闭每一个中断
为每个中断设置优先级
为每个中断设置目标处理器列表
设置每个外设中断触发方式（电平触发、边缘触发）
为每个中断设置组
将 SGI 转发到一个或多个处理器
每个中断状态可见
提供软件设置或清除外设中断的挂起状态的一种机制
中断 ID
使用 ID 对中断源进行标识。每个 CPU 接口最多可以有 1020 个中断。SPI 和 PPI 中断为每个接口特定的，SPI 为为所有接口共用，因此多处理器系统中实际中断数大于 1020 个。
CPU Interface
CPU 接口提供一个处理器连接到 GIC 的接口。每一个 CPU 接口都提供一个编程接口：
二、中断处理状态机
GIC为每个CPU接口上每个受支持的中断维护一个状态机。下图显示了此状态机的实例，以及可能的状态转换。添加挂起状态（A1、A2）
对于一个 SGI，发生以下 2 种情况的 1 种：
对于一个 SPI 或 PPI，发生以下 2 种情况的 1 种：
外设发出一个中断请求信号
软件写 GICD_ISPENDRn 寄存器
删除挂起状态（B1、B2）
挂起到激活（C）
挂起到激活和挂起（D）
对于 SGI，这种转变发生在以下任一情况下：
对于 SPI 或 PPI，满足以下所有条件，则发生这种转换
删除激活状态（E1、E2）
三、中断虚拟化设计
中断虚拟化概要
Hypervisor interface (GICH)
struct vgic_cpu的vgic_v2字段，struct vgic_cpu本身放在struct kvm_vcpu_arch，每个 vCPU 一份vgic-v2-switch.S中定义相关切换函数）vCPU interface (GICV, GICC in VM's view)
struct vgic_params vgic_v2_params）保存了这个物理地址ioctl设置该地址）映射到 GICV base 物理地址，然后把这个 GPA 作为 GICC base 在 device tree 中传给 VMVirtual distributor (GICD in VM's view)
struct vgic_dist）struct vgic_dist里的字段（在vgic-v2-emul.c文件中）struct vgic_dist放在struct kvm_arch里VM's view
VGIC设计
主要以以下4中case进行讨论，其中case4涉及vCPU调度，其他情况不涉及调度：
VGIC Distributor设计
VGIC Distributor 主要模拟 nr_spis 个 spis 中断
VGIC初始化
- 对于case 1、2 和 3，不需要 IPI 通信。case 4 需要 IPI 通信。
- 这些寄存器保存 GIC 的一些属性和处理元素（PE）的数量。
- getenable：直接从结构中读取内容。
- setenable：根据 vtop 和 ptov 设置配置 GIC。对于情况 1、2 和 3，不需要 IPI 通信。情况 4 需要 IPI 通信。
- 其他 vgicd-emu 寄存器与 isenabler 类似。
多架构下的GIC路由，vint实现配置
在arm下，用户通过配置分发器的vgic_irq，就可以控制每个引脚的中断信息deliver到哪个CPU。考虑到需要兼容x86和riscv架构，需要设计一个通用的路由表vint_irq_routing_table。
vint_irq_routing_table
TODO：
vint_set_routing_entry(vm, entries, nr, ue)
中断响应回调，直接调用vgic_irqfd_set_irq将中断注入到指定的vCPU中。
SGI软件生成中断
SGI是一种特殊的中断，由软件生成，通常用于在多核系统中实现CPU间通信。SGI的目标CPU由发送者指定，并且SGI可以被路由到一个或多个核上。
在虚拟化环境下，由于多个vCPU可能共享同一个物理CPU，hypervisor需要对SGI进行虚拟化，以确保VM之间的隔离性和透明性。
Hypervisor对SGI的拦截
在虚拟化环境中，当VM试图发送SGI时，通常通过修改guest的GIC相关寄存器来触发。VM本身无法直接访问物理的GIC Distributor（GICD）寄存器，因此这些写操作会被hypervisor拦截。
SGI的处理与路由
在SGI虚拟化中，hypervisor负责以下操作：
虚拟GIC的支持
为了让VM能够像使用物理GIC一样处理中断，hypervisor会提供虚拟的GIC接口（vGIC）。vGIC负责模拟GICD和GICC（CPU接口）的寄存器操作，并将这些寄存器映射到VM的地址空间。
虚拟GIC支持VM的SGI管理，包括：
PPI 私有外设中断
PPI通常用于管理特定于处理器的外设中断。在GICv2中，每个核心都有其专属的PPI，通常包括定时器中断和其他本地外设中断。在虚拟化环境中，hypervisor需要虚拟化这些中断，以便每个VM能够透明地访问和使用它们。
VM发起PPI请求
当VM中的vCPU需要处理PPI时，通常是通过对GIC的寄存器进行操作。例如，vCPU可能会读取或清除某个PPI的状态，这一操作需要经过hypervisor的拦截。
Hypervisor拦截请求
PPI的路由和分发
目标vCPU处理中断
Hypervisor的清理工作
SPI 共享外设中断
在虚拟化环境中，SPI（Shared Peripheral Interrupt，共享外设中断）是一种用于处理多个处理器核心共享外设的中断。与SGI和PPI不同，SPI是针对共享设备的中断，允许多个CPU响应同一外设生成的中断。hypervisor在虚拟化SPI时需要确保VM之间的隔离，同时提供对共享外设的正确中断管理。
SPI通常用于系统中那些可以被多个处理器访问的外设，例如网络适配器、存储控制器等。在GICv2中，SPI由GIC的Distributor（GICD）管理，允许多个处理器核接收来自同一外设的中断。在虚拟化环境中，hypervisor需要将SPI虚拟化为适合多个VM使用的形式。
VM发起SPI请求
当外设生成中断时，它将通过物理GIC将SPI传递给相应的处理器核心。在虚拟化环境中，物理中断首先会传递到hypervisor。
Hypervisor的拦截和管理
SPI的路由和重定向
目标vCPU处理中断
Hypervisor的清理工作
List Register
对于有虚拟化扩展的 GIC，Hypervisor使用 List Registers 来维护高优先级虚拟中断的一些上下文信息。
KVM关于VGIC的设计
Beta Was this translation helpful? Give feedback.
All reactions