通過這篇有趣的教程，熟悉運行在賽靈思 Zynq UltraScale+ MPSoC 上的 Xen 管理程序。

賽靈思和 DornerWorks 的系統軟件團隊在賽靈思的 Zynq? Ultrascale+? MPSoC 上啟動 Xen Project 管理程序時，我們發現可通過運行當年叱詫一時的流行電子游戲 Doom 來演示和測試系統。

神馬？！你不知道 DOOM？？（CS 你總知道吧 -__-||）

如何針對 Zynq UltraScale+ MPSoC 通過 QEMU 在 Xen 上運行 Doom 呢，在詳細介紹具體步驟之前，我們先來了解什么是管理程序，以及它們如何與 Zynq UltraScale+ MPSoC 上的處理器協同工作。

管理程序及其工作原理

管理程序是一種可虛擬化處理器的計算機程序。運行在虛擬化處理器上的應用程序和操作系統似乎完全擁有系統，但事實上管理程序負責管理虛擬處理器對物理機資源（例如存儲器和處理內核）的訪問。管理程序之所以流行，是因為能實現設計分區以及系統上運行的獨立軟件元素之間的隔離。

為了支持虛擬化，物理處理器必須提供一個供管理程序運行的特殊“模式”。因此，介紹處理器模式有助于理解管理程序如何完成處理器魔法。

所有處理器都有一些指令，這些指令可操作寄存器中存儲的值，并可讀寫存儲器。處理器的模式是指令和寄存器的集合，以及利用指令訪問寄存器和存儲器時要遵守的規則。為了便于解釋，我們以通用處理器為例來介紹，并使用與結構無關的術語。在這個實例中，處理器具有特定的寄存器、指令和模式。寄存器包括 RegisterA、RegisterB、RegisterC、UserProgramCounter、Register-Super 和 SuperProgramCounter。指令包括以下內容。

ADD Register3 Register1 Register2 將 Register1 與 Register2 相加，并把結果存入 Register3，即 Register3 = Register1 + Register2。

MOVTO Register2 Register1 將 Register1 中地址所指向的存儲器內容移動到 Register2。

MOVFROM Register2 Register1 將 Register1 的內容移動到 Register2 中地址所指向的存儲器。

ENTERSUPER 進入處理器的 SUPER 模式。

EXITSUPER 退出 SUPER 模式并進入 USER 模式。

在 USER 模式下，處理器的指令的功能受到限制。本例中，指令可對除 RegisterSuper 和 SuperProgramCounter 以外的所有寄存器進行讀和寫操作，處理器可執行除 EXITSUPER 以外的所有指令。

此外，在 USER 模式下，所有指令只能讀和寫一部分存儲器，例如從地址 0x0000_0100 到 0x0FFF_FFFF。在 USER 模式下，如果程序嘗試執行不應該執行的指令，或者訪問無權訪問的寄存器或存儲器位置，那么處理器將暫停出錯指令 (offending instruction)。

SUPER 模式下，處理器的指令可以讀/寫上述所有寄存器，包括 RegisterSuper 和 SuperProgramCounter。以上所列的所有指令，包括 EXITSUPER，都可以執行，另外，附加的指令 ENTERHYPER 也可執行(后面詳細介紹該指令)。此外，在 SUPER 模式下，指令可以訪問系統中的全部存儲器(從 0x0000_0000 到 0x7FFF_ FFFF)。

采用帶模式的處理器，使我們可以利用設計分區來更簡單地解決軟件工程設計問題。以上實例中，只有一種方法進入 SUPER 模式：執行 ENTERSUPER 指令。同樣，只有一種方法退出 SUPER 模式：執行 EXITSUPER。此外，在 USER 模式下程序只能訪問機器的部分存儲器。有了這種方案，我們可編寫一個程序讓處理器同時運行多個 USER 模式程序。這個“操作系統”(OS) 程序運行在 SUPER 模式，并管理在 USER 模式中運行的程序。

當 OS 運行時，會查看需要運行的所有 USER 模式程序，選擇一個運行，然后使用 EXITSUPER 這樣的指令通知處理器切換到 USER 模式以運行程序。所選的程序會一直運行，直到有事件導致處理器切回 SUPER 模式。這類事件可以是來自 USER 模式程序的 ENTERSUPER 指令，或外部事件，例如定時器，它可以不提醒正在 USER 模式下運行的程序將處理器切換到 SUPER 模式。無論切換如何發生，每當事件發生時，我們都可構建 OS 以根據相應策略相繼選擇和運行程序。當切換快速進行時，用戶認為 USER 程序同時運行。

USER HYPER 模式的用處是讓很多 SUPER 程序運行。SUPER 模式下的每個程序都可以是 OS；這些 OS 本身會讓很多 USER 程序并行運行。

SUPER 處理器模式還能防止 USER 程序干擾運行在 SUPER 模式的程序或其他 USER 模式程序。USER 模式程序的任何錯誤或違規都可被控制在該程序自身的實例中，不會破壞或干擾為 SUPER 模式操作保留的系統存儲器和寄存器。

聽起來很好，但能否用另一個模式實現一些功能？

對我們的機器稍加擴展，就可以引入 HYPER 模式。HYPER 模式可以讀/寫所有初始寄存器(RegisterA、RegisterB、RegisterC、UserProgramCounter、RegisterSuper 和 SuperProgramCounter)以及兩個附加寄存器：RegisterHyper 和 HyperProgramCounter。HYPER 模式下的指令包括初始集以及下面的斜體字。

ADD Register3 Register1 Register2 將 Register1 與 Register2 相加并把結果放在 Register3 中，即 Register3 = Register1 + Register2。

MOVTO Register2 Register1 將 Register1 中地址所指向的存儲器內容移到 Register2。

MOVFROM Register2 Register1 將 Register1 的內容移到 Register2 中地址所指向的存儲器。

MOVTOPHYS Register2 Register1 將 Register1 中物理地址指向的存儲器內容移到 Register2。

MOVFROMPHYS Register2 Register1 將 Register1 的內容移到 Register2 中地址指向的物理存儲器。

ENTERSUPER 進入處理器的 SUPER 模式。

EXITSUPER 退出 SUPER 模式并進入 USER 模式。

ENTERHYPER 進入處理器的 HYPER 模式。

EXITHYPER 退出處理器的 HYPER 模式。

SWITCHSUPER RegisterHyper 切換到 SUPER 程序，該程序將使用 RegisterHyper 中的值來執行下一個 SUPER 程序。

HYPER 模式中的附加指令和寄存器允許處理器切換哪個程序在 SUPER 模式中運行，就像 SUPER 模式允許處理器切換哪個程序在 USER 模式中運行一樣。HYPER 模式的一個特性是能夠切換哪個存儲器 SUPER 模式能看到；當一個在 HYPER 模式中運行的程序執行 SWITCHSUPER RegisterHyper 時，底層存儲器完全斷開。這就是說當 HYPER 模式中的程序執行了 EXITHYPER 之后，下個 SUPER 程序運行之時，SUPER 模式看到的實際物理存儲器與運行在 SUPER 模式中的另一個程序使用的物理存儲器不同。SUPER 模式程序仍使用相同地址訪問存儲器，但是該地址指向不同的物理位置。圖 1 顯示了執行 SWITCHSUPER RegisterHyper 前后的處理器存儲器視圖。

HYPER 模式很有用，是因為它允許很多個 SUPER 程序運行。SUPER 模式中每個程序都可以是 OS；這些 OS 本身可以讓很多 USER 程序并列運行.這意味著，我們可以在相同硬件上運行多個 OS，例如 Windows 和 Linux；在一個處理器上運行 20 個 Linux 實例；或者之間的任意組合。由于每個虛擬 OS 實例無法看到另一個 OS 實例，因此如果一個崩潰，不會使另一個實例也崩潰。HYPER 模式的特性還有其他應用：我們可以在多個 OS 之間對系統資源分區；監測 HYPER 模式下每個 OS 的執行，以在崩潰時重啟；以及在虛擬 OS 運行時密切關注系統狀態。

圖 1：HYPER 模式下執行 SWITCHSUPER RegisterHyper 的前后區別

隨著處理器從 USER 切換到 SUPER 模式，再從 SUPER 切換到 HYPER 模式，機器會賦予執行代碼更多特權。本例中，USER 模式程序只有權使用四個寄存器(RegisterA、RegisterB、RegisterC 和 UserProgramCounter)和四個指令：(ADD、MOVTO、MOVFROM和ENTER-SUPER)。此外，USER 程序只能讀寫 0x0000_0100 至 0x0FFF_ FFFF 的存儲器。一旦進入 SUPER 模式，處理器允許指令與 RegisterSuper 和 SuperProgramCounter 對話，并允許執行 EXITSUPER 和 ENTERHYPER。此外，SUPER 程序可以訪問從 0x0000_0000 至 0x7FFF_FFFF 的存儲器。

最后，一旦處理器進入 HYPER 模式，其指令就可以操作 RegisterHyper 和 HyperProgramCounter，而且程序可執行 SWITCH-SUPER 和 EXITHYPER。

?

圖 2：各種模式如環形所示

HYPER 模式還允許處理器讀寫所有虛擬存儲器，0x0000_0000 至 0xFFFF_FFFF，以及讀寫實際物理存儲器。這些特權等級通常被直觀地用環形來描述(圖 2)。主環，即 HYPER 環為特權等級較低的環賦予權限，最終可控制整個系統。

理論結合實踐

ARM? 創建處理器設計，供 ARM 合作伙伴構建芯片用。ARM 處理器包含一個或多個內核。每個內核實現一個 ARM 架構。例如，Zynq UltraScale+ MPSoC 包含一個 ARM Cortex?-A53 處理器及四個 ARMv8-A 物理內核(圖 3)。

當查看 ARM 處理器的文檔和代碼時，這種區別很重要；為了全面理解具有一個 ARM 內核的“芯片”，可參考有關架構 (如 ARMv8-A) 和處理器 (如 Cortex-A53) 的文檔。ARMv8 架構中有四個例外等級 (來源：ARM 架構參考手冊，D1-1404)：

1、例外等級 0 (EL0)，無需特權即可執行；

2、例外等級 1 (EL1)，執行 OS 以及任何執行特權指令的內容；

3、例外等級 2 (EL2)，允許硬件被虛擬化；以及

4、例外等級 3 (EL3)，允許在安全與非安全處理器狀態之間切換。

以下程序通常在這些模式下運行，如ARM 架構參考手冊 (D1–1404)中所述：EL0，應用程序；EL1，OS 內核以及通常所描述的相關特權函數；EL2，管理程序；EL3，安全監控器。我們的理論實例直接對應 ARMv8 執行模式 EL0 至 EL2：USER 對應 EL0，SUPER 對應 EL1，HYPER 對應 EL2。ARM 添加第四個特權等級，即 EL3；利用這個特權等級，我們可在安全與非安全環境之間切換 EL0 和 EL1。盡管 EL3 的使用是一個很重要的論題，能夠為架構增加大量的功能，但是在本實例中我們將其忽略，并著重介紹 EL0-EL2（利用管理程序的虛擬化）。如果對計算機如何保護金融交易感興趣，可以參閱 ARMv8 EL3 文檔(免費提供，需注冊)。這是非常好的參考文檔，從中可以獲得極為詳細的介紹。

圖 3：Zynq UltraScale+ MPSoC 架構

進入和退出例外模式

在真實系統中，模式之間的切換比我們的實例更復雜一些。ARM 總結了 ARMv8-A 架構的行為并在參考手冊中給出。手冊中介紹，只有在接到例外或從例外返回時，才能改變執行所處的例外等級。在接到例外時，例外等級只能升高或保持不變；在從例外返回時，例外等級只能降低或保持不變。只有三個指令能生成針對下個例外等級的例外：SVC (Supervisor Call)，生成針對 EL1 的例外；HVC (Hypervisor Call)，生成針對 EL2 的例外；SMC (Secure Monitor Call)，生成針對 EL3 的例外。這些指令取值范圍為 0-65,555，允許每個例外等級有 216 個系統調用。這些指令針對下個例外等級，而且是唯一可供運行在較低例外等級的程序從運行在較高例外等級的程序請求某些內容的機制。在我們的理論實例中，SVC 是 SWITCHSUPER，HVC 是 SWITCHHYPER。

PetaLinux 工具包含一組命令，以供用戶在賽靈思 FPGA 和 SoC 上輕松創建和擴展 Linux 系統。

在前一個部分，我們介紹了能夠讓運行在 USER 模式(EL0)的程序進入 SUPER 模式 (EL1) 的事件。大多數運行在 USER 模式的程序生成的事件是請求存儲器。當運行在 EL0 中的用戶空間程序從運行在 EL1 中的 OS 請求存儲器時，這個用戶空間程序的 C 代碼可能調用函數 malloc()，再由該函數調用 mmap() 或 sbrk()，以從 OS 請求一個指向可用存儲器的指針。在 ARMv8-A 架構中的 Linux 上，這個過程在幕后轉化為 SVC 系統調用。該系統調用會把處理器轉換為 EL1，從而將控制權送回 OS，后者會解讀調用內容并提供正確的響應——本例中是指向所請求存儲器區域的指針，或者是一個錯誤，用以指出沒有可用存儲器。

演示創建和工具

現在我們來介紹我們團隊在 Zynq UltraScale+ QEMU Model 上運行 Doom 時所采用的步驟。這些步驟展示了如何獲得和構建運行演示所需的每個組件，如何運行以及以什么順序運行每個組件，以及如何與演示交互。成功完成該演示之后，你會獲得一個環境，用來在上面進行實驗，以了解 Xen 管理程序在仿真的 Zynq UltraScale+ MPSoC 上的運行情況。還需要將此遷移植 Zynq UltraScale+ MPSoC 芯片，這可作為練習由用戶來完成。

想玩 DOOM 嗎？

為了讓過程更簡單，賽靈思提供基礎的根文件系統，這樣用戶就無需花時間和精力自己構建。此演示所需的所有下載內容在以下網址中均有提供： inx.com/Doom+on+Xen+Demo。

該演示首先通過更新由賽靈思提供的預編譯根文件系統 (rootFS)，可包含所需的組件。然后，利用賽靈思的 PetaLinux 工具運行演示。rootFS 包含運行于 Linux 系統上的大部分程序——具體來說就是用來啟動系統的一組腳本，以及用來實現系統的應用程序與函數庫集。我們用來擴展演示中的基礎 rootFS 所使用的兩個工具分別是 Buildroot 和 PetaLinux。我們使用 Buildroot 為賽靈思提供的基礎 rootFS 構建 Doom 二進制文件，同時使用 PetaLinux 創建 rootFS 的剩余部分并引導演示。

Buildroot

Buildroot 是一個簡單的構建系統，用于為 Linux 系統創建 rootFS。它使用 make menuconfig 接口，這是一個用來配置 Linux 內核本身的常用方法。Buildroot 包含對 PrBoom 的默認支持，這對于本演示很有幫助。(PrBoom 是我們所使用的 Doom 游戲的 GNU 通用公共許可證 [GPL] 版本。這里我們會穿插使用 PrBoom 和 Doom 這兩個術語。 )Buildroot 對 Xen 構建不提供本地支持(盡管它可創建用于構建 Xen 所需的所有庫和工具鏈)，因此賽靈思提供 Xen、Xen 工具和為用戶預編譯的 Xen 庫以及其他一些所需的庫，以讓過程簡單直觀。

PetaLinux

PetaLinux 工具包含一個命令集，以便讓用戶在賽靈思 FPGA 和 SoC 上輕松創建和擴展 Linux 系統。該演示使用 petalinux-build 和 petalinux-boot 命令。petalinux-build 命令用于創建全部所需的組件。petalinux-boot 命令(外加幾個變量)用于啟動在 QEMU 仿真器上運行的所有組件。介紹 PetaLinux 工具中的所有命令超出了本文的范圍，但是通過此演示系統應該很容易發掘這兩個命令和其他命令的功能。參考PetaLinux 工具文檔 — 參考指南 UG1144 (v2015.4) 了解更多信息。

項目先決條件

該項目需要一個運行 Linux 的工作站或虛擬機，具有滿足 UG1144 (v2015.4) 中所列的 PetaLinux 工具安裝要求的環境，而且環境中需要安裝賽靈思 PetaLinux Tools v2015.4 版本。

一旦 Doom 啟動，你就可以使用鍵盤和鼠標控制游戲。應記住，可能需要點擊 ESC 鍵來開始游戲。開始游戲咯！

步驟 1：構建 ROOTFS

首先，我們需要構建 rootFS。從賽靈思下載 doom_demo.tar.gz，打開下載目錄中的一個 terminal；你可在以下網址中找到全部所需文件： +on+Xen+Demo。我們將該目錄稱為 。

解壓文檔。

$ cd
$ tar -xzf doom_demo.tar.gz && cd doom_demo

我們會看到一個文件夾，我們將把它存到根文件系統(一個用于 Dom0，另一個用于 DomU)?，F在，我們需要構建 PrBoom，并復制到 rootFS。

首先，需要下載 Linux 內核，這樣我們隨后就可以構建 rootFS。我們使用 v4.3 標簽。

$ git clone -b v4.3 https://github.com/tor- valds/linux.git

下載 Buildroot 源文件，并更改到 Buildroot 目錄。

$ git clone https://git.buildroot.net/buildroot && cd buildroot

現在我們需要配置 Buildroot，以構建可以使用的套件。

$ make menuconfig

我們選擇以下選項：

Target options ---> Target Architecture ---> AArch64 (little endian)
Target packages —> Games ---> prboom ---> [*]
Target packages —> Games ---> shareware Doom WAD file ---> [*]

應自動選擇全部所需的庫。

$ make # (這需要幾分鐘時間，取決于機器。)

現在，我們將所有 PrBoom 相關文件復制到 targetfs 目錄，確保我們在 buildroot 目錄下的 ./output/target/ 目錄。

$ for i in $(find ./-name ‘*oom*’); do cp ${i}
/doom_demo/targetfs/${i}; done

現在，我們完成了 Buildroot 操作。我們移到上一個目錄 doom_demo 目錄。

$ make # Build the host and guest rootFS.(這需要幾分鐘時間，取決于你的機器。)

注意：可能還存在額外配置選項，這主要取決于使用的內核版本。這些額外配置選項未被我們提供的配置預先選擇。使用默認選項即可(需點擊回車鍵)。

步驟 2：構建基礎設置

接下來，我們為平臺構建嵌入式系統軟件的剩余部分，包括引導裝載程序、ARM Trusted Firmware (ATF)、Linux 內核和設備樹。賽靈思的 PetaLinux 工具讓這個過程簡單直觀。我們創建一個針對賽靈思 ZCU102 開發板的 PetaLinux 項目。參考 2015.4 UG1144 和 AR#66249 中 QEMU 和 MPSoC PetaLinux 的快速入門材料。訪問china.xilinx.com ，將 ZCU102 BSP (板支持包)下載到
目錄下。

$ cd
$ petalinux-create --type project -s
/ Xilinx-ZCU102-v2015.4-final.bsp -- name doom_demo_zynqMP

這樣將在 /doom_demo_zynqMP 中創建我們的 PetaLinux 項目。

我們轉到 PetaLinux 項目，并構建 PetaLinux。

$ cd /doom_demo_zynqMP
$ petalinux-build

現在，我們需要為本用例手動編輯設備樹。

編輯 xen-overlay.dtsi 文件 (subsystems/linux/ configs/device-tree/xen-overlay.dtsi)。

將 dom0 下的 'reg = <0x0 0x80000 0x3100000>;' 替換為 'reg = <0x0 0x80000 0x4100000>;'

將 dom0 下的 'xen,xen-bootargs = "console=dtuart dtuart=serial0 dom0_mem=512M bootscrub=0 maxcpus=1 time r_ slop=0";' 替換為 'xen,xen-bootargs = "console=dtuart dtuart=serial0 dom0_mem=512M bootscrub=0 maxcpus=4 timer_ slop=0";'

將 dom0 下的 'xen,dom0-bootargs = "console=hvc0 earlycon=xen earlyprintk=xen maxcpus=1";' 替換為 'xen,dom0-bootargs = "rdinit=/bin/sh console=hvc0 earlycon=xen earlyprintk=xen maxcpus=4";'

編輯 zynqmp.dtsi 文件 (subsystems/linux/configs/ device-tree/zynqmp.dtsi)。

將 dom0 下的 'compatible = "cdns,uart-r1p12";' 替換為 'compatible = "cdns,uart-r1p8", "cdns,uart-r1p12";' 現在，手動構建 Xen 設備樹。

$ dtc -I dts -O dtb -i ./subsystems/linux/con- figs/device-tree/ -o ./images/linux/xen.dtb ./ subsystems/linux/configs/device-tree/xen.dts

最后，我們需要將 Peta- Linux 構建的 rootFS 替換為我們此前構建的 rootFS。之所以這樣做，是因為 PetaLinux 不包含 PrBoom，因為我們提供自己的 rootFS。我們還需要將 xen.ub 鏡像替換為賽靈思預先構建的鏡像，因為 Xen 和 Xen 工具版本必須匹配。

$ rm /doom_demo_zynqMP/images/linux/ Image && rm /doom_demo_zynqMP/images/ linux/xen.ub
$ cp /doom_demo/Image /doom_ demo_zynqMP/images/linux/Image && cp / doom_demo/xen.ub /doom_demo_zynqMP/im- ages/linux/xen.ub

使用 u-boot 引導加載程序引導。

$ petalinux-boot --qemu --u-boot --qemuargs= "- net nic -net nic -net nic -net nic -net us- er,net=192.168.129.0,dhcpstart=192.16 8.129.50,host=192.168.129.1,hostfwd=t cp:127.0.0.1:5900-192.168.129.50:5900"
> setenv serverip 192.168.129.1
> tftpb 4000000 xen.dtb; tftpb 0x80000 Image; tftpb 6000000 xen.ub; bootm 6000000 - 4000000
# /boot.sh
# /xen-doom.sh 1

步驟 3：開始演示

現在，我們可以打開虛擬網絡計算 (VNC) 查看器，并在運行 QEMU 的機器上連接 localhost:5900 以觀看 Doom 游戲。(注意：以上命令行只能重定向 5900 端口，因此當開始演示時只能連接到第一個 Doom 實例。如果想連接多個實例，需要為 QEMU 添加更多 hostfwd 變量，并連接到下個可用的端口[5901 用于下個實例，5902 用于第三個實例，以此類推]，然后將這些實例連接。)

一旦 Doom 啟動，你就可以使用鍵盤和鼠標控制游戲。應記住，可能需要點擊 ESC 鍵來開始游戲。還應記住，你已經很長時間沒玩 Doom 游戲了，因此你可能走不了多遠。 別氣餒。使用自己構建的系統絕對“可行”。

XEN 深入探討

正如“Zynq MPSoC 獲得 Xen 管理程序支持”(賽靈思中國通訊，第 93 期)中所介紹， Type 1 管理程序在本機硬件上運行，Type 2 管理程序不是軟件的最底層，而是托管在 OS 上。Xen 屬于 Type 1 管理程序(圖 4)。

?

圖 4：作為 Type 1 管理程序，Xen 在本機硬件上運行，虛擬機在 Xen 之上運行

以前，我們提到了虛擬處理器(也稱虛擬機)。在 Xen 中，這些被稱為域。特權最高的域被稱為 Dom0；無特權的客戶域是 DomU 域。

Dom0 是 Xen 管理程序在引導時創建的初始域。它是特權域，并驅動平臺上的設備。Xen 將 CPU、存儲器、中斷和定時器虛擬化，為虛擬機提供一個或多個虛擬 CPU、系統存儲器的一部分、一個虛擬中斷控制器和一個虛擬定時器。除非配置為其他方式，否則 Dom0 可直接訪問所有設備并驅動它們。Dom0 還運行一組名為半虛擬化 (PV) 后端的驅動，為無特權虛擬機提供對磁盤、網絡等設備的訪問權。Xen 提供用于發現和初始通信設置的所有工具。作為 DomU 的 OS 通過運行相應的 PV 前端驅動程序來獲得對一組通用虛擬設備的訪問權。根據 DomU 的數量，單個后端可服務多個前端。有一對適用于所有最常見設備類型(磁盤、網絡、控制臺、幀緩沖器、鼠標、鍵盤等)的 PV 驅動程序。PV 驅動程序通常位于 OS 內核（即 Linux）中。幾個 PV 后端也可以在用戶空間中運行，通常在 QEMU 中。前端在存儲器的共享頁上使用簡單的環協議連接后端。從 Dom0 與管理程序交互要求程序使用定義的管理程序調用(類似于系統調用)。Xen 提供一個名為 Xen Tools (也可寫成 xen-tools)的、帶有庫的參考工具箱。xen-tools 包含一個名為 xl 的程序，該程序可與其他程序一起檢查狀態和創建客戶機。

利用設備半虛擬化，可在管理程序與客戶機之間就如何進行通信達成協議。常見的通信協議為 Xen Bus 和 VirtIO。

xl 中的“create”命令要用到描述客戶機的配置文件，如果配置文件規定客戶機需要一個由 VNC 會話支持的虛擬幀緩沖器 (VFB)，那么 xl 會在 Dom0 用戶空間中自動啟動虛擬化代碼(本演示中，為每個客戶機啟動一個)。

doom VM 的配置文件如下所示：

# 客戶機名稱
name = "guest1"
# 要引導的內核鏡像
kernel = "/boot/Image"
# 內核命令行選項
extra = "console=hvc0 rdinit=/doom.sh"
# 最初存儲器分配 (MB)
memory = 56
# VCPUS 數量
vcpus = 1
vfb = ['type=vnc, vnclisten=0.0.0.0']

XEN 中的設備

為客戶機提供設備有三種常用方法：仿真、半虛擬化和直通 (圖 5)。對于設備仿真，當客戶機向仿真設備的存儲器寫入時，寫入操作會觸發陷阱。陷阱通常就是頁面錯誤。陷阱使處理器能夠切換到管理程序，以仿真設備。仿真是靈活的，但速度慢，因為要處理所有陷阱，而且要有人為所有需要仿真的設備編寫模型。而且，很難找到方法來加速仿真，因為幾乎沒有硬件加速；完全是軟件方法。

圖 5：方案、半虛擬化和直通方案的對比

利用設備半虛擬化，可在管理程序與客戶機之間就如何進行通信達成協議。通常有一個共享的存儲器區域(以及協議)，這看起來像一個設備，而且管理程序在該區域處理請求。例如，為了在 Linux 上支持半虛擬化幀緩沖器，Linux 前端驅動會把從用戶空間獲得的幀緩沖器寫入共享存儲器區域；然后使用管理程序調用向管理程序發信號，以通過后端驅動來輸出幀?？蛻魴C只能通過半虛擬化驅動程序與主機 (Dom0)和其他客戶機 (DomU) 對話。這種方案的優勢是：用戶可以在很多客戶機之間共享設備；運行快速；客戶機可以運行大部分都沒修改的內核。要求的變動在標準接口下面，因此對于應用程序以及內核其余部分來說，前端驅動程序看起來就像正常的網絡接口、磁盤或其他設備。支持客戶機通信的兩個常用協議是 Xen Bus 和 VirtIO。

在直通模式下，主機將設備“交給”一個客戶機。這意味著每次只有一個客戶機可以使用該設備。

設備性能與安全

一般來說，與通過直通方式提供的設備相比，仿真的設備性能比較低；半虛擬化方案則趨向于具備足夠性能。半虛擬化方案和仿真方案的優勢在于管理程序可以讓設備訪問多個實體，而不會將這些實體相互暴露。

原理簡介

Doom-on-Zynq UltraScale+ MPSoC 的處理上下文環境就像洋蔥一樣有很多層(圖 6)。Cortex-A53 中是四個 ARMv8 內核。在每個內核上，管理程序運行在 EL2 中，客戶機（Dom0 或 DomU）運行在 EL0/EL1 中。每個 DomU 客戶機都運行 Linux；Doom (PrBoom) 運行在用戶空間中。Doom 使用簡單直接媒體層 (SDL)，通過 SVC 指令(最終)與幀緩沖器前端驅動對話。幀緩沖器前端將緩沖器寫入 Dom0 建立的共享存儲器區域。前端驅動通過協議（例如 Xen Bus 或 VirtIO）使用 HVC 指令(最終)與 Dom0 上運行的虛擬化代碼通信。在 Dom0 上運行的虛擬化代碼提供一個用于顯示的后端，然后該后端由虛擬化代碼的 VNC 服務器進行編碼，并通過網絡送到 VNC 客戶端。

?

圖6：X86 架構上從 PetaLinux 工具啟動 QEMU

此信息和演示能夠為管理程序的進一步研究和實驗提供很好的基礎。當你能夠在 QEMU 上用仿真來運行演示之后，就可使用 PetaLinux 工具在 Zynq UltraScale+ MPSoC 芯片上運行。