【无标题】VirtIO简介

大家好，欢迎来到IT知识分享网。

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

一、传统完全虚拟化系统

效率问题
在传统的完全虚拟化环境中，虚拟化系统必须捕捉这些请求，然后模拟物理硬件的行为。尽管这样做提供很大的灵活性（即运行未更改的操作系统），但它的效率比较低。
在传统虚拟化系统中，会使用QEMU通过纯软件的方式来模拟I/O 设备，包括键盘、鼠标、显示器，硬盘和网卡等。




缺点
不同的虚拟化解决方案都会给操作系统带来负担，负担的大小取决于各个解决方案的需求。其中的一项开销为设备的虚拟化。
每次I/O 操作的路径比较长，需要多次上下文切换，也需要多次数据复制，所以性能较差。

二、VirtIO引入

1.效率问题

2.什么是VirtIO？

3.纯软件模拟的设备和Virtio设备的区别

virtio 省去了纯模拟模式下的异常捕获环节，客户操作系统可以和QEMU 的I/O 模块直接通信。

4.为什么要用VirtIO？

在完全虚拟化的解决方案中，guest VM 要使用底层 host 资源，需要 Hypervisor 来截获所有的请求指令，然后模拟出这些指令的行为，这样势必会带来很多性能上的开销。
由于不同 guest 前端设备其工作逻辑大同小异（如块设备、网络设备、PCI设备、balloon驱动等），单独为每个设备定义一套接口实属没有必要，这个时候，就需要一套通用框架和标准接口（协议）来完成两者之间的交互过程，virtio 就是这样一套标准。

VirtIO架构

从总体上看，virtio 可以分为四层，包括前端 guest 中各种驱动程序模块，后端 Hypervisor （实现在Qemu上）上的处理程序模块，中间用于前后端通信的 virtio 层和 virtio-ring 层，virtio 这一层实现的是虚拟队列接口，算是前后端通信的桥梁，而 virtio-ring 则是该桥梁的具体实现，它实现了两个环形缓冲区，分别用于保存前端驱动程序和后端处理程序执行的信息。
virtio 和 virtio-ring 可以看做是一层，virtio-ring 实现了 virtio 的具体通信机制和数据流程。或者可以说，virtio 层属于控制层，负责前后端之间的通知机制（kick，notify）和控制流程，而 virtio-ring 则负责具体数据流转发。

KVM/QEMU 的 vitio 实现采用在 Guest OS 内核中安装前端驱动 （Front-end driver）和在 QEMU 中实现后端驱动（Back-end）的方式。前后端驱动通过 vring 直接通信，这就绕过了经过 KVM 内核模块的过程，达到提高 I/O 性能的目的。

Front-end
A kernel module in guest OS
Accepts I/O requests from user process
Transfer I/O requests to back-end
Back-end
A device in QEMU
Accepts I/O requests from front-end
Perform I/O operation via physical device

Virtqueue

desc：用于存储一些关联的描述符，每个描述符记录一个对 buffer 的描述
available ring：则用于 guest 端表示当前有哪些描述符是可用的
used ring：则表示 host 端哪些描述符已经被使用

使用 Virtio 的完整虚机 I/O流程

Host 数据发到 Guest：

1. KVM 通过中断的方式通知 QEMU 去获取数据，放到 virtio queue 中
2. KVM 再通知 Guest 去 virtio queue 中取数据
   
   Descriptor table —— 存放数据的 buffer 是一种分散-聚集的数组，由 desc 结构来承载。
3. 当 guest 向 virtqueue 中写数据时，实际上是向 desc 结构指向的 buffer 中填充数据，完了会更新 available ring，然后再通知 host。
4. 当 host 收到接收数据的通知时，首先从 desc 指向的 buffer 中找到 available ring 中添加的 buffer，映射内存，同时更新 used ring，并通知 guest 接收数据完毕。
   

Virtio示例

VirtIO在Linux中的实现

Guest OS 中，在不使用 virtio 设备的时候，这些驱动不会被加载。只有在使用某个 virtio 设备的时候，对应的驱动才会被加载。每个前端驱动器具有在管理程序中的相应的后端的驱动程序。

Virtio_net

1. 多个虚机共享主机网卡 eth0
2. QEMU 使用标准的 tun/tap 将虚机的网络桥接到主机网卡上
3. 每个虚机看起来有一个直接连接到主机PCI总线上的私有 virtio 网络设备
4. 需要在虚机里面安装 virtio驱动

Virtio_blk框架介绍

在virtio-blk磁盘中，采用io_write函数将virtqueue的编号写到相应的寄存器，导致虚拟机退出，进行前端到后端通知，采用中断注入方式实现后端到前端的通知，并通过IO环(vring)进行数据的共享，IO模型也随之发生变化。

参考链接：https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.qavf.overview/topic/virtfs_arch.html https://www.qnx.com/developers/docs/7.1/#com.qnx.doc.qavf.overview/topic/socket_arch.html

Virtio各版本对比

AAOS

概述

通过虚拟化，Android Automotive OS (AAOS) 的单个或多个实例可以作为GuestOS与其他汽车操作系统一起运行。这可通过 VirtIO来实现，可让 AAOS 针对通用虚拟化平台运行，进而使 AAOS 客户机虚拟机能够在不同的 Hypervisor 系统或硬件平台之间移植。
AAOS 平台团队已使用 BlackBerry QNX 的 QNX Hypervisor for Safety 在 Qualcomm SA8155P 芯片组上开发并验证初始参考平台版本 trout 1.0。

架构

1.音频

2.GNSS

3.蓝牙

AAOS 中为支持 VirtIO 所需进行的大部分更改都涉及到 Android 通用内核中 HAL 实现级别及以下级别的更改。Android 框架使用 AAOS 客户机虚拟机内核中的 VirtIO 驱动程序与一个与硬件无关的通用 HAL 进行通信，而 VirtIO 驱动程序使用 VirtIO 协议与主机端的 VirtIO 设备进行通信。主机端的 VirtIO 设备可以使用 SoC 专用设备驱动程序来访问物理硬件。

VirtIO SCMI

当 AAOS 作为客户机虚拟机与其他汽车操作系统一起运行时，Android 可能无法直接访问传感器。在这种情况下，Android 客户机虚拟机上的 Virtio-SCMI 驱动程序和主机虚拟机上的 VirtIO-SCMI 设备用于访问传感器。AAOS 虚拟化参考平台提供了一个与硬件无关的通用传感器 HAL，它可用于基于 ARM 的 SoC 以访问传感器。

参考链接：https://source.android.com/docs/devices/automotive/virtualization/architecture?hl=zh-cn