第一章节 QNX 的虚拟环境变量

对应的印刷约定.

主要是一些编码的格式.
makefile 还有各种的登录模式.

slash(/). 分割路径.

去社区或者网站获取对应的支持.

-----------------------------------------------------------------

popek/ goldberg 理论.

参考.
https://zh.wikipedia.org/wiki/%E6%B3%A2%E4%BD%A9%E5%85%8B%E4%B8%8E%E6%88%88%E5%BE%B7%E5%A0%A1%E8%99%9A%E6%8B%9F%E5%8C%96%E9%9C%80%E6%B1%82.

等价性：一个运行于VMM下的程序，其行为应与直接运行于等价物理机上的同程序的行为完全一致。
(有一些部分虚拟化的设备)

资源控制：VMM对虚拟资源进行完全控制。
(安全性:
除了 guest 直接访问的一些 pass-through(直传)的设备, hypervisor 应该一直维护硬件的资源的控制.

)
效率性：机器指令中经常使用的那一部分应在没有VMM干预下执行。

这个理论可以参照一本书.

-----------------------------------------------------

nomentclature.
命名法.

terminology.
术语.

-----
device, vdevs.

guest, qvm 主持一个guest, guest 在 qvm 中运行.
spell it out: 讲清楚，是关闭进程还是 guest os.

-----------------------
host, 在大多case中, 术语主机host 不是一个主机电脑(那种桌面，笔记本用来连接目标系统加载新的镜像或者调试的).
但指向 hypvervisor 或者 hyppervisor 中的一些东西, (例如, cpus 指引客户线程去退出客户模式, 并且在 host模式继续) .

如果上下文不能将 host 指定清晰, 我们使用"development host" 去指向桌面.
用"host domain" 或者 "hypervisor host" 去指定 hypervisor 以及它的组件.

讨论优先级或者异常等级时, 我们会用 hypervisor host或者 hyper host domain 来判断,
hypervisor上面跑的一些进程.

-------------------------

qvm.

qvm 是一个在hypervisor 中运行的, guest os 在qvm上运行.

hyper 为每个guest 开启一个qvm 进程,
3个guest，你就有3个qvm.

at times: 有时
qvm 有时在 hypervisor host domain 允许下运行.
有时在它所包容的 guest 的低优先级下运行.

--------------------

vdev.

虚拟设备vdevs 有时候来表示 hypver 虚拟化的任何设备，

vdevs 的例子包含了一个 “中断控制”, 或者以太网的设备控制器.

如果我们曾经当作一个设备指向一个虚拟设备，会很疑惑，请让我们知道.

-----

Terminilogy 就是一个未来的术语的集合.

=======================================================================================

文件名

我们使用以下术语 (nomenclature, term, terminology), 来命名对应的qnx的虚拟化环境.

<1>.prefixes 前缀.
hypervisor 后面跟随着的是遗传发布的数字.

<2>.suffixes 后缀.

.build 这是为了qnx 以及 hypervisor,其他os的请看对应的其他文档.

.img 可以加载的img, 可以包含一个或者多个镜像.

.qvmconf. 虚拟机的配置文件， qvm进程起来之后解析来集合 VM.

<3>
例子.

下面告诉我们如何撰写文件名字.

----------------------------------------
hypervisor release-board.type.

release 是 hypervisor 的发布number,
board 是硬件平台的名字.
type 就是文件的类型. build 或者 img 等等.

hypervisor2.0-broadwell.build.

----------------------------------------------

guestos,type.
guestos: qnx70, qnx66,linux44

如果同样的os有多个实例， qnx7a.build 以及 qnx7b.img.
linux 以及其他的使用主机的术语.

--------------------------

VM 配置文件.

qvm 进程的一个配置文件是这样的:

guest.qvmconf.

qnx7a.qvmconf. qnx7b.qvmconf.等等.

=====================================================================================

Architecture.

架构.

hypervisor 2.0 包括微内核以及 qvm的多个实例.

这个图展现了一个 qnx hypervisor的架构以及访问所有虚拟以及物理设备的一个配置文件.
不是所有的客户机-设备配置文件都被展示了;
那些只是 illustrate(说明) 了一些可能的配置.

****
注意pass-through 以及 shared 配置.

message handles 以及 private memory. 等等.？？？？

---------------------------------------------------------------------------------

支持的架构与硬件.

Arm 与 x86.

注意:
对于所有的 ARM 与 x86 平台, hyper host 需要64位的硬件，但是支持 64位和 32 位的客户机.
guest os 必须在hyper host 运行的硬件架构上进行编译.
例如, Arm 32 以及 64 客户机 arm64 的架构.

---------------------------------------------------------------------------------------

CPU 特权等级.

一个 cpu 特权等级控制运行在处理器上的程序，对资源的访问权限，例如记忆区,
I/O 口, 以及特殊的指定.
一个客户机比 hyper 更加低特权级别,
一个在客户机上运行的程序有更加低的特权,< guest level.
这个架构从非信任的软件组件中提供了硬件-等级的安全.

------------------------------------------------------------------------------------------

设计安全状态.

hyper 提供了两种的设计安全状态(DDSs).
如果一个内部的和外部的检测机制警报(提醒) 它有一个情况, 它不是被设计以其他任何方式来处理.
(说白了有个case ，之前没有定义，无法处理这个case?)

VM DSS

如果一个未定义的条件被限定在 VM( 接待 guest的一个qvm 进程实例).
hyper 终止了 qvm 进程实例. (以 SIGSEGV 信号).
终止了托管qvm process的实例，终止了它的guest.
(按照之前所讲的，终止了 qvm, 也就是终止了 guest).

Hypervisor host DSS

hypervisor = qnx os + 虚拟化的插件.
导致os 移动到它的 DSS的同样的条件导致了 hypervisor host 移动至其 DSS.
这就是, 如果未定义的条件不限定于 VM， hypervisor 关闭了.
这个DSS 和 QOS 2.0 DSS, 一样.

警告.
qnx hypervisor 2.0 不是一个安全认证的产品, 它必须用在安全相关的产品系统.

如果你想在一个安全相关的系统中去跑一个hypervisor,
你必须当它变成可用的时候获取对应的qnx hyper 参数.

==============================================================================

Virual machines.
虚拟机.

一个运行的 hypervisor 组合了一个 hypervisor 的微内核 + 它的虚拟化库 (libmod_qvm.a)
以及一个或多个虚拟机进程的实例.(qvm).

什么是虚拟机?

paragrphy 1.在一个qnx hyper 环境中, 每一个 vm 是一个 qvm 进程实例.
qvm 进程是在 hyper 主机运行的一个 OS 进程.
kernel 之外的.

每一个实例都有一个标识标记它所以微内核知道它是一个qvm进程.
(还有之前说的一些命名规则,但是这个是为了让微内核知道).

paragraphy 2.
如果你记得 VMs的任何事情, 记住从guest os 的视角看,
托管guest 的Vms 就是一个硬件.
这意味着 ,只是作为一个运行在物理板子的 os ，期望某些硬件特性，
(架构, 板子-指定, 内存, cpus ，设备等).

一个os 运行在 VM 上的期待那些特性：
一个客户机在 vm 上运行的必须满足客户机的需求.

pagraphy 3.
当你配置一个VM, 你在组装一个硬件平台.
不同的是替代了集合物理内存卡, CPUs ,等等.
你指定了你机器的虚拟组件,
qvm会根据你指定的进行创建和配置.

对于事情将出现在哪的规则和真实的板子一样:

1. 不要安装两个东西尝试回应同样的物理地址.

2. 你的VM 配置集成的环境必须是一个你即将运行的能够准备处理(时间，消息)的环境.

硬件仿真也能在其他方向做的好. 一个VM 不需要知道"它的客户机做的什么比硬件需要知道一个os干什么的多”，程度上的多.
(意思是vm 不需要知道特别多，相对于以前的硬件知道 os一样)

更多的配置 VM 的信息，看 "assembling and configuration VMs"

qvm serives.

每个 qvm 进程提供了关键的 hypervisor 技术, (qvm 就是我们说的vm, 加载配置文件，就是os的硬件配置平台).

VM startup

为了创建一个 guest os 运行的虚拟环境,
qvm 当它启动时候做以下的事情:

1. 读取，解析以及验证vm 的配置文件, (*.qvmconf) 并且配置 "进程命令行的启动输入"的信息,
如果配置信息非法并且打印一个有意义的错误数据到log，就退出.

2. 设置内部即时的 stage tables,(应该是设置页表).

3. 创建配置它的vm, 包含:

*** ram 是内存 rom 是硬盘存储.
1). 分配读写的内存以及 rom(硬盘存储)
2).为每一个虚拟化之后呈现给 guest os的cpu 规定一个线程 .(为cpu开一个线程)
3).规划 passthrough 设备让他们对guest都是可得的.
4). 为被托管的 guest os定义和配置虚拟设备(vdevs).

VM operation(vm 操作)
在操作一个 qvm 进程需要做以下的事情:

traps(陷阱就是捕获) 访客(guest)
1. 捕获出站和入站guest访问尝试并且决定对他们做什么(如果地址指向一个 vdev,调用 vdev 代码(访客退出, vdev代码完成后，然后访客进入= 退出-> 进入的流程); )

2. 在退出一个物理的cpu之前，保存guest 的上下文.

3.在将 guest 重新执行的时候, 恢复guest 的上下文.

4. 照顾到所有的错误处理.

5. 执行(需要确保虚拟机的完整性的) 维持性操作

Manage guest contexts.
管理客户机的上下文.

在虚拟化的环境中, cpu虚拟化插件的职责是从一个客户机的操作中识别出什么时候客户机要退出.
当一个 cpu 触发了一个客户机退出, 但是, 是qvm进程实例托管了保存着客户的上下文的客户机,
当一个客户机已经完成了它的任务并且已经准备好重新进入, 进程实例(qvm) 重新存储了客户机的上下文.

manage privilege levels

qvm进程实例在 guest 进入和退出的时候管理特权等级, 确保 guests 能够运行，并且系统免受错误代码的影响.

在客户机进入时候, qvm 实例向cpu 请求给出客户机(它需要运行的, 定义好的)特权等级,但是更多的是.
当客户机退出的时候, qvm 进程实例要求 cpu 去返回到需要在 hypervisor host 运行中的特权等级.

(所以特权等级是时刻都在调整的).

只有cpu的硬件能够改变特权等级. qvm 进程执行需要cpu 改变特权等级的操作.
这种机制(因此操作), 特定架构.

guest access to vitual and physical resources.

访问虚拟和物理资源的客户机.

每个qvm 进程实例管理它托管的客户机对所有虚拟的和物理资源的权限.

当一个客户机尝试去访问它的客户机-物理内存中的地址.
这个访问可以是以下的一种,
托管了客户机的 qvm 进程检查了权限尝试，并且回应描述如下:

Permitted:

guest在访问它自己拥有的存储区,
qvm 进程不做任何事.

Pass-through devices:

guest在尝试直接访问物理地址,
并且 guest 的vm 知道有直接权限,
qvm 进程实例不做任何事情, guest 直接和设备去沟通.

virual devices:
guest 尝试去访问一个分配到虚拟设备的地址(无论虚拟的或者是部分虚拟的???)

qvm 进程实例请求相应的特权等级改变, 并且传递执行到它的代码或者请求的设备.
(代码改变或者设备驱动的等级改变)

例如, 一个客户机 CPUID 请求触发 qvm 实例去仿真硬件以及对客户机的精确回应, 和硬件对非虚拟化的系统的回应一样.

fault:

客户机尝试访问一些它没有权限的内存.
qvm 进程返回一个不正确的一个错误到客户机.

上述的是经过cpu的访问尝试, DMA 的访问控制被 SMMU 管理所管理.

==================================================================================================

memory.

在 QNX 虚拟化的环境中, "客户机能够见到的当做连续物理内存的" 客户机-物理内存实际上是 "虚拟化组装的不连续的主机-物理内存".

qnx 虚拟环境的客户机使用内存来:

1.普通操作; (虚拟环境下的一个内存)
2. 访问 pass-through 设备; (pass-through memory)
3. 和其他的客户机分享信息. (shared memory)

memory in a vitualized environment.

虚拟化环境的内存.

在 qnx 虚拟化环境, 一个配置 1G RAM 的客户机将见到1 GB 可用,
就跟它在虚拟化环境下见到的RAM 一样.
这个内存分配在客户机看来就是一个物理内存.

实际上内存是由虚拟化配置的从不连续的物理内存中分配的.
intel 管它叫 guest-physical memory, (概念出现了，就是传说中的 guest0物理的内存).

为了简洁，我们将使用 guest-physical 内存, 不管平台.(看"guest memory").

当你在 qnx 虚拟化环境, 配置并且访问内存的时候, 去记住以下的比较重要:

1. 分配给 guest 的所有内存以及其他的使用不能超过板子上的物理内存.

2. 内存分配必须在 qnx 7.0 的system page size(4KB) 的倍数.

3. 一个客户机的见到的内存是由不连续的内存块组成的.
这个展现给 guest的 guest-physical 内存就像（在一个非虚拟化的系统中展现给它的一样).
(又强调一遍).
例如, 在x86系统中，和传统设备的差距相同.

4. 一个客户机见到的物理地址显然实际上就是 guest-physical内存中的 guest-physical addresss,
当hyper-host 创建一个 VM 时,是由 qvm 进程分配的.

5. 一个客户机见到的地址(guest-physical) 和物理地址(主机地址) 没有对应， (to which) 然而 guest-physical
在虚拟机层进行最终转换.

一张图: 指导 guest os 见到连续的物理内存，
实际上是由物理内存中的不相关的区域中的虚拟化配置出来去集成.

这张上面的图展现了一个简单的指导在qnx虚拟化系统, guest 内存分配是由物理内存的一大块不连续内存分配的.
为了简化这个图, Guest1 的内存分配是不完整的, 为了清晰起见, 一个隔离已经被添加进 guest 之间.
注意一些物理内存的区域也被保留了.
(例如, 为了板子架构在指定位置需要的设备 )，并且不能够分配到 guest.

pass-through memory

guests 以 pass-through 设备的身份访问物理设备
需要将这些设备映射到 (可以访问他们的)内存区域,
注意为了一个 pass-through 的设备的 guest-physical 的地址 ,没有必要和 hypervisor-domain的 host-physical 地址一样.
换而言之, 在 guest 能够见到的 physical address 和 hypervisor host domain 见到的 physical address 之间没有对应.
(但是会转换)

例如, 设备A 可能在 Guest 1 的物理地址的0x100处配置. (0x100 表示的是一个已经被虚拟化后的一个物理地址)

这个设备为了guest 1 在同样的位置上(0x100) 的可能会被配置成一个 pass-through 设备，
所以当 guest1 需要访问设备的时候，它看起来像在 0x100.
但是, 我们应该记住当一个 guest 看起来像在一个物理地址,
它其实正在看向一个 guest-physical 地址，
转换成 host-physical 内存的其他地址，表示 "0xc000000".

一张图,
guest 见到的 pass-through 设备的 guest-physical 的地址被当做是一个物理设备, 与设备的 host-physical 地址并不对应.
(意思是没有映射，和shared 区别, 但是在虚拟化层可以进行转换)
(从设备角度有几个映射)

----------------------------------------------------------

shared memory

部分物理内存可以在 guests 之间进行分配.
Guests 将会使用一个虚拟设备例如 vdev-shmem 来附加到相同的物理地址(PA) 并且使用共享内存域去分享数据.
触发对方，只要数据可得到或者已经被读了.

(共享内存只适合大数据传输，不适合做消息通信,
你操作的是一片内存，加握手，就会延时其他进程，
全部要分段???只适合大数据传输,没有队列消息).

两个客户机的内存分享的指导,
每个客户机将内存视作自己的内存.

可以参见 "using your hypervisor system "中的 "memory sharing".

----------------------------------

configuring memory

为了虚拟机配置内存, 你必须为了每部分的系统配置内存.
你没必要为VM 在一大块里面分配内存.
相比较而言, 你要分配镜像需要的内存,
然后你各种设备的内存, 等等.

许多系统已经保留了内存区域,
这特别是对 x86 系统，需要许多在特殊的位置的 vestigial(残余的) 设备 ,
这些适应 guests 的规则跑在虚拟环境中,
因为 OS们期待 vestigial(残余的) 设备可以展现出来.

当你为VM 分配内存时,它应当是权宜(衡量多方balance) 以及有效的 "在guest-physical 内存"只去指定 "可以加载的镜像" 的位置 ,
并且让 qvm 进程决定设备的最佳位置, 共享内存，等等.

如果一个 RAM 位置被用来客户机的 "可加载的镜像",
(ram 就是内存,掉电丢失的).
客户机被配置成在这个地址(host 地址???) 去寻找镜像文件在它的内存中 .

(起了qvm之后，已经配置好虚拟化内存的地址, 包括所谓的镜像文件的地址，也可以读进来???, 就是物理板子上已经全部flash进去了,
并且镜像文件已经读到内存了.
然后跳转到对应的地址，让guest 运行????).

此外, 如果使用 qvm "配置文件,加载组件" 去装载你的可启动的镜像文件.
(就是硬件加载启动文件),
你加载镜像的地址必须匹配你客户机的配置.(说白了这个加载镜像要跟客户机启动的时候一致)
(如果你不指定地址， qvm 会为你照看这个).

举个例子.
对于qnx 客户机来说, 你可能做以下的东西,

1.为 guest 镜像分配一个起始地址, 0x80000000.
ram 0x80000000, 128M.

2.加载可启动的镜像到这个位置.

3.在guest 的buildfile 去指定启动.
这个镜像文件ifs 应该是kernel 吧.

(
你可以看一下bsp的一些启动
还有一些 guest laucher.
).
----------------------------------

DMA 设备包含器 (smmuman).

hypervisor 使用一个 IOMMU/SMMU 管理器(summan),
确保了没有 pass-through 设备能够访问 host-physical 内存到它还没有明确地被授予权限.

整个内存的地址布局????

============================================================================================

Devices.

qnx hypervisor 提供客户机访问物理设备的权限,
包括 pass-through 以及 shared 设备，以及虚拟设备, 包括部分虚拟化的设备.

关于设备权限.

当你配置你的qnx 虚拟化环境(hypervisor, 虚拟机的qvm 进程, 以及客户机).
你需要去分配物理设备和虚拟设备(vdevs) 到hypver 和 guests.
为了正确地做，你需要知道, 不仅仅一个设备是物理的或者虚拟的设备,
并且是一个物理的或者虚拟的设备的类型, (设备类型也要分虚拟的和物理的？？？？)
因为这个决定了:

1. 如果guest 或者 hypervisor 必须包含一个设备驱动.
2. 如果托管了一个客户机的qvm 必须包含相关的 vdev.
3. 如果 guest 需要知道它运行在一个虚拟化的环境内.

只是作为在一个非-虚拟化的系统
操作系统里面的设备驱动必须匹配物理板子上的一个硬件设备.
在虚拟化的系统中，客户机中的设备驱动必须匹配一个 "vdev",虚拟设备.

*******
例如, 如果你使用 vdev-p1011 vdev(如下配置: vdev vdev-p1011 loc 0x1c090000 intr gic:37).
你必须告诉你的客户机使用一个 PLO11 设备在位置0x1c090000 以及中断 37.

你不能通过客户机的指导去使用一个 UART 设备,
说" earlycon = msm_hsl_uart, 0x75b0000", 并且期望它能够找到 PLO11 设备，
比你在非虚拟化的环境中要做的多.

********

配置 hypervisor host,qvm 进程, 设备，看configuration 那一章节.

--------------------------------------------------------------------------------------------

物理设备

一个物理的设备可以是hypverisor host 或者 guest 的独家使用，或者可以被分享.

虚拟环境中的物理设备 (或者简单的设备) 和非虚拟化环境中的设备是一样的.
他们需要驱动, 断言中断以及收取信号,等.

在qnx虚拟环境中运行的客户机可能直接访问一个物理设备或者通过一个虚拟设备(访问物理设备).
或者他们可能被禁止访问一个设备,

物理设备的访问被虚拟环境的配置所控制.
一个物理设备可以配置成:

1. 对特别的客户机是专属可得到的; (pass -through)
2. 在客户机内部共享, 不是所有的设备都可以共享. (shared devices)

pass-through 设备.
hypervisor 系统中, pass-through 设备是 (有直接的和独立的访问的权限)的客户机的一个物理设备 .
因为它是直接的以及独立的，这种物理设备的访问类型可能比通过虚拟设备的访问要快.
或者说比和其他客户机或者 hypver host 分享的访问要快.
(要比shared 快?)

为了使用一个 pass-through 设备, guest 必须有它自己的物理设备的驱动.
没有 vdev 在托管guest'的qvm 中被需要,
没有 hypvervisor 本身需要的驱动.
(定义,就是pass through 不需要vdev从 host 到 guest 的这些映射?????)

hypervisor host domain 只需要知道它必须从物理设备那规划一些中断直接到客户机.
并且直接传递来自客户端的信号.
所有的相互作用是在客户机和设备之间的;
hypervisor 只负责去辨别以及允许来自设备的中断的通过,以及来自于客户机的信号.

在客户机启动之前, pass-through 设备必须在 *.qvmconf 文件中配置, 为了将会托管 guest 的一个虚拟机.

注意:

只有虚拟化系统的一个居民被允许在任何时间访问 pass-through 设备.
如果 host 拥有一个客户机要求是pass-through 设备的设备;
在guest 在它的虚拟环境中启动一个这个设备的驱动之前, host必须终止设备驱动.

相似的, 如果一个客户机拥有一个作为pass-through 的设备
在其他客户机在它的空间内使用这个设备之前,它必须在它的虚拟空间中终止这个设备驱动,

(就是同一时间，总允许只有一个可以访问此设备，无论是hyper或者 host????)

简而言之, 永远不要配置相同的 pass-through 设备超过一个简单的客户机.

和复杂设备的 pass-through 属性一起运作:

一些设备(例如 audio 以及 video 设备) 由多个硬件接口组成, 为了操作正常需要特定的非常的配置 .

一个知识丰富的 (知道和了解如何使用所有的设备接口，并且可以在vm定义中可以正确定义他们 )的系统设计者应该能够让任何复杂的设备
以一个 pass-through 设备在qnx的hypervisor系统中正常运行.

联系qnx services 获得更多的客户机之间的复杂设备一些共享.

shared 设备.

在一个 hypervisor 系统中, 共享设备可以是被超过一个客户机来使用的物理设备,
或者是被一个或者多个客户机以及 hypvervisor 自己本身.

有几种方法和模型用来设备共享, 包括了,

1.referred sharing (推荐分享)
2.mediated sharing(调和分享)

hypervisor 提供了服务类似于 tcp/ip, 共享内存, virtqueue 支持,

(https://www.ibm.com/developerworks/cn/linux/1402_caobb_virtio/index.html. )
***virtio 这个应该是通用接口.
你可以用来设备共享.
这些服务和你实现的配置将取决于你的系统的需求.

注意:
qnx hypvervisor 支持 vdevs 使得 audio 以及 graphics 的物理设备的分享，
请联系 qnx 代表.

referred sharing
推荐共享

在推荐共享的模式下, 将要共享的物理设备被指派给一个客户机,
该客户机对设备有绝对控制权.

如果物理设备被当作一个 pass-through 设备来访问,
guest 需要一个物理设备的驱动.(就是正常的一个dev)

如果物理设备通过一个虚拟设备(vdev)被访问, 托管客户机的qvm 进程必须有对应的虚拟设备(vdev),
并且客户机和 hypervisor 都需要对应的设备驱动.???就是驱动之上的虚拟化???
为了虚拟化的设备(guest), 并且为了真实的物理设备(hypervisor)

其他客户端也需要使用类似 tcp 机制来访问物理设备, (或者共享内存和 virtqueue，机制 )和guest 去沟通,
来控制设备，并且根据需求去传输数据.

例如, 假设两个客户机跑在一个hypervisor 系统上.
guest 0 是一个qnx 安全相关的客户机.
而 guest 1 是一个 “花园式”的没有安全需求的 linux 系统的客户机.
他们都需要访问一个设备去输出声音, guest 0 去发射报警音, guest1 播放音乐.
(仪表以及中控).

我们分配 audio 设备作为一个 pass-through 设备到 guest 0.

托管guest 1 的vm的 qvm进程里面的 audio 虚拟设备(vdev??) 被设计来和另外一个qvm进程的虚拟设备共享数据的.

(应该是设备的共享,而不是仅仅是这个设备的混音???，所以设备会共享，内部实现还是不一样的，对于驱动而言，会生成几个设备)
并且它是被配置来知道这个其他的虚拟设备是在 qvm进程为了托管guest0 的虚拟机的.

****:所以共享设备知道在其他地方是被共享的.
在这种配置下, guest1 上所有的audio 设备活动被称为 guest 0 来处理.

当在 guest 0 的qvm进程的虚拟设备, 接收guest 1 的中断和数据,
它将他们传递给 guest1 的qvm的虚拟设备.
当 guest1 的qvm进程的虚拟设备从 guest1 接收 audio devices的信号和数据,(也就是播放的一些样本数目，或者是一些音频流???)
它将这些传递给 guest0 传递给到它的 audio 设备驱动以及, 最终，传递给物理audio设备.

自从 guest 0 控制了audio 设备的所有的输入以及输出.
它可以设置优先级来确保安全相关的进程和线程在输入和输出到 "花园式" 的系统以及它的进程上取得优先权,
****(gardenvariety 就是普通的,老百姓)
甚至拒绝去和其他guest os或者设备合作, 如果合作可能导致自己的安全相关的活动至于危险中.
***jeoprady 危险.

Mediated sharing
调和共享.

调和共享模式和推荐共享模式相似,不同的是在调和模式下,
它是hypvervisor的进程而不是一个假设负责控制物理设备的接口, 并且确保配置的属性是被认可的 guest os.

在这种模式下,被分享的设备被指派到hypervisor自身.
每个VM 的qvm进程中的虚拟设备连接到 hypervisor 的中间件(调解员),
这个调解员决定哪些中断和数据可以从物理设备到客户机,
并且哪些信号和数据是从客户机到hypervisor的设备驱动.
最终, 到了物理设备.

这个调节员也保证了配置的属性是被尊敬的(认可的),(例如确保安全相关的活动有最高的优先级.)
甚至拒绝和一个可能对系统上的其他guest 或者hypervisor 本身有害的活动的 guest或者 device.

注意:
调节器进程不需要定居?? 在hypervisor host.
他们可以在其中一个guest中。

注意的是，但是，依据这种设计, 一个客户机失败将会导致
调和分享没有定义的行为.
(没法处理这种错误么?)

综上,一个在guest里面，一个在hyervisor 里面.

最好画一个交互的图.
--------------------------------------------------------------------------------------------
虚拟设备

一个虚拟设备可以仿真一个物理设备,或者它可以做一个半虚拟化的设备(一个虚拟设备, 不存在确定的物理设备).

虚拟设备(或者说 vdevs) 只存在虚拟化环境.
他们是运行在 hypervisor 层的软件代码以及要么仿真一个物理设备.
或者提供一个物理设备提供的功能而没有仿真任何指定的物理设备.(???没有仿真，直接提供么)

为了使用vdev, guest 需要一个驱动, 就像它需要一个驱动在非虚拟化的环境中去使用物理设备一样.
****vdev 也需要对应的驱动去生成.

一个vdev 可能从未访问一个物理地址, 或者它会像一个(全都直接回应guest 并且在guest和物理地址间传递请求和回应的)
中间件运行.

在一个 hypervisor 系统中，在qvm进程里, hypervisor 为"托管客户机的虚拟机 "提供了 vdevs.
托管在虚拟机的客户机收到来自于虚拟设备的中断,并且发送信号给它.
和它在物理的硬件设备一样.
guest 和系统上的任何的物理设备有直接联系;
例如一个设备有可能甚至不存在.

guest 需要一个为它将使用的各种 vdev 一个设备驱动,
就跟当它运行在一个非虚拟化的环境并且需要访问一个物理设备, 需要一个设备驱动,

hypervisor 支持虚拟设备的以下类型.

1.仿真设备
2.部分虚拟化设备.

注意:

当前的 hypervisor发布, 没有 qnx的支持, 不支持用户-创建的vdevs.
如果你的hypervisor 系统实现需要 vdevs 这次发布没有包含进去,
请联系你的 qnx 代表去获取 qnx 工程服务写 vdev 权限.
(连创建vdev 都要花钱去买. 具体你内部的中断是怎么玩的???)

-------
仿真设备.

一个仿真的 vdev(或者简单的vdev) 是一个 (为guest 仿真一个真实的物理设备)虚拟设备.
以下的是qnx 虚拟化环境中仿真 vdevs 的关键点:

1. 为了使用 vdev ,一个 guest 不需要知道它是运行在虚拟化环境的.
它和这些设备都是相互作用的, 和它和物理设备的交互方式一样,
并且它没有指示它正在与虚拟设备合作，或者没有硬件设备能够参与其中.
(并不需要知道运行在虚拟环境的,这个是由hypervisor 出版的)

2. vdev 仿真了一个真实的物理设备(例如, 一个x86 的电脑键盘).实际上,
一些 vdevs(例如电脑键盘) 存在简单的因为一个运行在 x86 平台上的期望它在那.
(存在的意义)

3. 仿真的物理设备存在或者不存在系统上.
(或许根本不存在)

4. 取决于物理设备的类型, 仿真的vdevs 可能所有事情都是自己处理,
(例如仿真一个计时器芯片(vdev-timer8254)), 或者它可以当作 guest 和一个真实的物理设备的中间件(例如 vdev-ser8250).

5. 客户机为了 vdev 可以使用同样的设备驱动，和(它在非虚拟化环境中为仿真的物理设备使用的)一样,
(都要有设备驱动，生成的代码都一样，但是设备需要做映射????)

------

部分虚拟化的设备.

部分虚拟化的设备是一个虚拟设备的类型, 他们是运行在 hypervisor 层的一个软件代码,
但是这个代码不仿真任何指定的硬件设备.

反而, 一个部分虚拟化的设备提供了 "可能在非虚拟化环境中由物理设备(或者几个物理设备) 提供的" 功能,
但是没有仿真一系列硬件的一个约束.

一个传统的部分虚拟化的设备有运行在客户端的代码，和运行在客户端（后端）的一个代码；
举例, 一个运行在客户机的文件系统的设备驱动,连接到一个运行在hypervisor host 的块设备驱动.

部分虚拟化设备的关键点包括:

1. 为了使用部分虚拟化的设备, guest 必须知道它正在运行在一个虚拟化的环境.
例如, 为了使用 virtio-net, guest必须知道它正在运行在一个虚拟化的环境,
只有因为 virtio-net 没有对应的物理设备( 它只是作为一个部分虚拟化的设备).

2. 不存在物理设备完全对应部分虚拟化的设备.

3. 客户机必须有适当的驱动以及接口去和部分虚拟化的设备进行合作.

部分虚拟化的设备需要一些初始投资(例如写驱动),
但是这些驱动可能比 (必须仿真一个硬件组件的)vdevs更加有效.
例如, 仿真一个（提供了一个控制终端的）串口接口可能导致许多客户机退出以及返回.
一个 virtio-console 驱动(一个部分虚拟化的串口接口) 提供了同样的功能.
但在 guest端的开销更小.

部分虚拟化的设备不一定是 VirtIO 设备，
VirtIO 是简单的并且当前受欢迎的标准.

==========================================================================================

基于优先级的调度

在qnx的虚拟化环境中去理解基于优先级调度如何影响系统行为.

hypvervisor 线程优先级和客户机线程的优先级.

和其他的任何的高级的软件系统一样, 为了在带有 qnx hypervisor 系统中正确的配置调度优先级,
需要一个对你的系统需求和你的系统能力都有直观的了解.

为了开始, 你应该记住以下:

1. hypervisor host 并不知道它的虚拟机上运行着什么, 或者客户机如何调度他们自己内部的软件.
当你在客户机中设置优先级, 这些优先级只被客户机知道.

2. 虚拟 CPUs (vCPUs) 是被 qvm vCPU 调度线程所调度的;这些线程存在于 hypervisor host 域.

3. 客户端的线程优先级和 hypervisor host 中的线程优先级没有关系.
qvm 处理 vCPU 调度线程的相关属性决定哪个 vCPU 可以访问 pCPU.

这下面的这张图显示了客户机内的属性只和客户机内部相关,并且对"两个竞争的客户机获取对 pCPUs 的访问权" 没有影响,
阴影区域显示了两个竞争的 vCPU 线程获取pCPU 的权限的其中一种.

(没有统筹统一的优先级，就是大类是区分,而后才是 vcpu 之后的一个优先级)
图5. 访问一个pCPU 最重要的优先级就是 qvm 进程的 vCPU 的优先级.

如果两个 vCPUs 为一个单个的物理 CPU(pCPU) 竞争, vCPU 更高优先级的线程会立即获取 pCPU.
客户机内部运行的线程的优先级对这个访问是没有影响的.
上述的例子中:

1.guest 1 中的线程有一个比 guest0 中更高优先级的线程.

2. hypervisor 为 guest 0 提供了 vCPU 的线程(200)，比为guest 1提供了 vCPU的线程(100) 有一个更高的优先级.

3. 所以，内部guest 0 线程获取了 pCPU 的访问权限并且运行.

4. 内部的 guest1 线程被阻塞了直到 guest0 中的线程资源自愿地锁住.

简而言之, 决定性的线程就是 qvm 进程的 vCPU 调度线程的优先级.

客户机退出

以下引起了客户机退出:

客户机的停止;
一个 vdev 的访问; 这种类型的退出没有必要引起客户机去放弃 cpu 的控制;
host 上的一个中断(包括内部处理器的中断 (IPIs)).
一个虚拟的定时器, 例如仿真在 intel 8254 芯片的 vdev.
一个指导, 例如一个 CPUID 指导.

==========================================================================================

时间

在 qnx hypervisor 上的客户机的定时器总是滞后于 host的时间, 但是hypervisor 采取正确的操作来最小化偏移.

drift 偏移

hypervisor 系统中的客户机的时间也是虚拟化. 也就是说, 托管客户机的 vm(qvm 进程实例)
提供了一个虚拟的 “计时器滴答” 和 (客户机期望在它的环境下找到的)虚拟的硬件定时器.
所以, hypervisor host 控制着它的客户机见到的时钟。
hypervisor host 给客户机的时钟做的就是当一个客户机退出的时候, 对客户机有一个重要的影响,
特别是客户机的时间预算.

当一个客户机退出的时候, hyervisor host 可以要么让客户机时钟运行, 要么停止客户机的是中国,
这些选项中没有一个是理想的.

guest clock runs during exit
退出的时候，客户时钟正在运行.

如果 hypervisor host 允许客户机的时钟去运行,
客户机时钟保持了和 hypvervisor host 时钟的同步,
仅仅被偏离量分开,
host 开始计算时间以及客户机开始计算时间之间经过的时间.

允许时钟跑偏客户机的时间计算, 但是, 在客户机退出以及它的再进入的周期被添加到时间流逝,
为了客户机需要退出的的任务.
任务会消耗他的时间预算并且可能会被抢占,举例,除了退出，没有做实际上的任何事情.
(应该就是cpu 资源的使用).

guest clock is stopped during exit.
当客户机退出的时候, 停止客户机的时钟, 解决了存在的跑偏客户的时间预算.
当客户机退出的时候, 客户机的时钟停止直到客户机重新进入, (重新进入，会开始计时)
并且客户机只会计数它真实运行在任务的时间预算的时间.
但是,客户机在各个客户机退出的时候停止, 这个时钟落后 host clock 增加地. 这个落后称之为偏移.

在每个客户机退出的时候, 偏移增加. 如果偏移量被允许不正确的增加,
遇到可能阻止其按照要求运行的行为:
客户机可能会丢失时间器中断,
它一天中的时间可能会不正确的增加，等.

Skipping,

跳过.

为了给客户机他们时间预算的合理控制, qnx hypvervisor 在每一个客户机退出的时候, 停止客户机的时钟.
但是, 为了减轻偏移的影响以及避免最终创建的不争取的偏移的问题,
qnx hypervisor 周期引起客户机的时间 "向前跳过";
也就是说, 它设置了客户机的时间前移一部分偏移的时间(也就是时间的矫正).

hypervisor 只会向前跳过客户机和host之间的落后的一部分,
因为客户机的向前跳过时间歪斜客户机的时间计算.

例如, 考虑到一个客户机落后 host 有10ms的偏移.
这个客户机正在运行 foo,
如果hypervisor 让客户机时间向前整个10ms,
这些10ms(foo 没有使用的)尽管如此,但是还要foo 收费,
当foo 开始和它结束的时候,因为时间内的增量包含了 10ms的的向前跳跃.
所以, hypervisor 只会让客户时间向前偏移的一小部分，为了将"skip" 平均分配给客户机的活动.

如果你在你的客户机已经实现了任何类型的时间预算,
你应该考虑到所有偏移量和纠正性跳过的这些预算的影响.
特别,记住.

1. 客户机已经退出了所有的 vCPUs, skipping是可能的; 这意味着在不规则的间隔发生的 skip的必要性.

2. hypervisor host 在每个它要这样做的机会上将客户机的时间向前跳跃.

3. hypervisor host 只会向前跳跃当前偏移量的一部分.

4. 总是有一些偏移量, 并且这些偏移的变量贯穿客户机的生命周期.

如何找回一个客户机的当前的时间偏移的信息,
看"finding current time drift " 在“monitoring, troubleshooting and Tuning”

-----------------------

offset

一个客户机在host开始之后可以启动,所以一个客户机需要比它的托管者计算时间要晚(在hypervisor 系统之外的衡量).
不同的是简单的偏移量, 只有在它关心的时间里面是和偏移相关的.
(drift).

==========================================================================================

共享资源

在一个 hypervisor 系统中，除了共享内存中一小块区域，
内存和设备只被一个单独的实体所拥有.

多个运行在不同的虚拟机中的客户机可能使用同样的系统资源, 例如一个物理的cpu,
这些资源的管理完全是 hypervisor的domain.

系统集成者的职责限制于(非常重要) 位每个虚拟机配置正确的 vPCU 的个数的问题,
设置他们的优先级, 并且绑定 vCPU 线程去指定特定的物理 CPUs, 如果需要的话.

其他资源, 例如内存和物理设备, 通过 VM 配置分配到指定的虚拟机,
hypervisor 使用来组装虚拟机(看见"配置"这一章).
这些资源变成运行在各个虚拟机之间的客户机的独立的属性.
他们不能够在客户机之间分享，像两个独立的板子之间的硬件设备一样.

共享内存

当你为你的虚拟机配置 RAM 和 ROM, 让qvm进程为内存选择 host-physical 地址通常是最佳方案.
因为进程不会给超过一个虚拟机分配一个同样的内存位置.

一个小型的共享内存区域可以是一个在guest 于不同虚拟机之间传递数据的有效的机制,
但是, 如果你需要配置一个共享内存区域, 你可以这样做, 使用一个vdev 例如 vdev-shmem, 取代 hypervisor的共享内存服务,
共享内存如何实现的,
看"memory sharing" 在 "using your hypervisor system".

共享设备

像内存一样, 设备不能直接分享.
虚拟设备(无论是仿真还是部分虚拟化.) 是隐式的(在qvm 进程代码),或者他们是配置进VM 的共享的对象 ;
因此,他们是虚拟机专有的.
物理设备直接分配给客户机当作 pass-through 设备,
或者分配给hypervisor host, 并且被客户机通过一个虚拟设备去访问.

如果一个实体而不是 (需要访问设备的)物理设备的拥有者 ,它必须经过设备的拥有者,
就像如果设备物理的在另一个板上做的一样.
如果设备由 hypervisor host 拥有的, 这就称之为中介分享;
如果被其他客户机拥有, 这就称之为 “参考分享”.
更多的信息，请见这章的 "shared devices".

第一章节 QNX 的虚拟环境变量相关推荐

【高数】高数第一章节——极限无穷连续与间断
高数第一章节--极限&无穷&连续与间断 0.博主高数相关章节目录 1.数列极限 1.1 定义(important) 1.2 例题-数列极限 1.3 收敛数列性质 1.3.1 有界性 1 ...
由巨型计算机到微型计算机,微机原理第一章节：基础知识.ppt
微机原理第一章节:基础知识 * * * * * * * * * * * * * * * * * * * * * * * * 微型计算机原理与接口技术中原工学院电子信息学院 (电子教案) 总目录 ...
STM32 LWIP实验第一章节--了解以太网
STM32 LWIP实验第一章节--了解以太网心有猛虎,无所畏惧! 一.了解以太网流程: 借鉴: https://www.xitongtiandi.net/wenzhang/xp/23235.htm ...
【软考软件评测师】第一章节面向对象测试方法
[软考软件评测师]第一章节面向对象测试方法第一章节面向对象测试方法 [软考软件评测师]第一章节面向对象测试方法第一部分知识点集锦 1.面向对象的测试分为哪几个阶段 2.面向对象单元测试主要 ...
《烟灰缸里的回忆》第一章节
<烟灰缸里的回忆>第一章节 2010年04月22日思维不停的被现实所拉扯着像是没有任何出路,回忆就是那一抹永远都逃离不了的黄昏,必须去接受现实. 小的时候总是充满着幻想,并且伴随着好多难 ...
在c语言中我叫做符号变量,问渠网-C语言基础-第一节关键字符号与变量
一.关键字与符号: 1.关键字 auto double int long break else long switch case enum reg ...
shell脚本编译规范（编写第一个脚本，脚本变量的作用，类型，了解read命令，let命令，环境变量和预定义变量）
文章目录 shell脚本编译规范 shell脚本应用场景 shell编程规范编写第一个脚本执行脚本文件四种方法 echo输出友好提示信息管道与重定向管道操作符号"|" sh ...
c语言第一章节测试,计算机二级C语言教程章节测试：字符串
计算机二级C语言教程章节测试:字符串 (61) 函数调用:strcat(strcpy(str1,str2),str3)的功能是 A) 将串str1复制到串str2中后再连接到串str3之后 B) 将串 ...
第一章节初始类和对象
调用类的方法 1.如果需要在类的外部进行成员变量和成员方法调用,则在定义时,需要指定访问修饰符为public 命名空间 1.命名空间有两种方式: 一种是系统命名空间,另一种是自定义命名空间 2.命名空 ...

第一章节 QNX 的虚拟环境变量

第一章节 QNX 的虚拟环境变量相关推荐

最新文章

热门文章