Linux閱碼場 - Linux核心月報(2020年08月)

關于Linux核心月報

Linux閱碼場

Linux閱碼場核心月報欄目，是彙總當月Linux核心社群最重要的一線開發動态，友善讀者們更容易跟蹤Linux核心的最前沿發展動向。

限于篇幅，隻會對最新技術做些粗略概括，技術細節敬請期待後續文章，也歡迎廣大讀者踴躍投稿為閱碼場社群添磚加瓦。

本期月報主要貢獻人員：

張健、廖威雄、chenwei、柱子、王立辰、M.J、轉角遇到貓、冥王、李帥

1. 體系結構相關

1.1 Add UEFI support for RISC-V

1.2 Control-flow Enforcement

1.3 Unify NUMA implementation between ARM64& RISC-V

1.4 x86/uaccess: Use pointer masking to limit uaccess speculation

2. Core Kernel

2.1 Generalizing bpflocalstorage

2.2 tailcalls in BPF subprograms

2.3 io_uring: add restrictions to support untrusted applications and guests

2.4 Core-sched v6+: kernel protection and hotplug fixes

3. 裝置驅動相關

3.1 Intel Platform Monitoring Technology

3.2 Net: add support for threaded NAPI polling

4. 記憶體管理

4.1 memcg: Enable fine-grained per process memory control

4.2 huge vmalloc mappings

4.3 Support high-order page bulk allocation

5.檔案系統和Block IO5.1 ext4: add free-space extent based allocator

複制

5.2 virtiofs: Add DAX support

複制

5.3 xfs：解決2038年時間戳上限5.4 block/bpf：用eBPF實作IO請求的過濾5.5 fs：新增支援讀寫的Linux NTFS

複制

6.網絡6.1 在MPTCP中引入SYN Cookie功能6.2 BPF7.虛拟化和容器7.1 Enable Linux guests on Hyper-V on ARM647.2 Remove 32-bit Xen PV guest support7.3 HSM driver for ACRN hypervisor7.4 mm/virtio-mem: support ZONEMOVABLE7.5 Support virtio cross-device resources7.6 KVM:Add virtualization support of split lock dection7.7 KVM: PKS Virtualization support

複制

目前核心版本：

- Linux 5.8 (August 2, 2020)

- 開發版本Linux 5.9-rc2 (August 23, 2020)

1. 體系結構相關

本月x86，ARM64，RISC-V三大架構都有更新，有之前提到過的

MTE更新檔（由ARM64的maintainer Catalin繼續更新）
RISC-V的UEFI支援
Intel的硬體控制流完整性（CFI: Control Flow Integrity ）技術（CET: Control-flow Enforcement)
還有tglx發起的超大（38個）更新檔集“x86, PCI, XEN, genirq …: Prepare for device MSI”

1.1 Add UEFI support for RISC-V

更新最頻繁的是Atish Patra的Add UEFI support for RISC-V [1]，一個月内更新了三次。和七月相比，目前的工作已經支援了Linux啟動和runtime services。其中runtime services已經通過Linux啟動和fwts（ FirmwareTestSuite [2]）測試。RISC-V的EFI支援同時複用了部分ARM64runtime的代碼。

[1] Add UEFI support for RISC-V https://lwn.net/Articles/829130/

[2] FirmwareTestSuite https://wiki.ubuntu.com/FirmwareTestSuite

1.2 Control-flow Enforcement

CET技術（控制流強制技術）是英特爾推出的一項用于阻止ROP和JOP攻擊JOP的安全技術。CET技術的原理是使用影子寄存器，追蹤線程堆棧中的調用及傳回位址，在程式傳回或調用時做校驗比對，若有問題則抛出異常。詳細細節可參考"Intel 64 and IA-32 Architectures Software Developer'sManual"。目前Yu-cheng新增了shadow stack 部分和 indirect branch tracking, ptrace，并測試運作穩定。

1.3 Unify NUMA implementation between ARM64& RISC-V

這個系列patch通過複用ARM64的NUMA實作讓RISC-V也能支援NUMA系統。

1.4 x86/uaccess: Use pointer masking to limit uaccess speculation

2018年的Spectre變種1（bounds-check bypass），借助邊界檢查時cpu會投機通路（speculate access），實作攻擊。之前x86在 copy_from_user中使用LFENCE減緩這種攻擊。但是LFENCE有點重了。

來自Redhat的Josh把LFENCE替換為 array_index_nospec，後者原本的用途是數組通路越界時，把index被鉗位為0，進而避免攻擊者通路原本不允許通路的超過數組範圍的位址。由于64位核心中，使用者空間位址為低位址（以一串0開頭），核心為高位址（以一串1開頭）。如果給 array_index_nospec傳入0和使用者位址的最大範圍（ user_addr_max()），當攻擊者試圖從使用者空間傳入核心位址（即大于 user_addr_max()的位址時，該位址會被 array_index_nospec設為0。進而避免了攻擊者從使用者空間“偷到”核心的資料。

2. Core Kernel

Core Kernel主要是bpf相關的更新比較多。

2.1 Generalizing bpflocalstorage

該更新檔意在使一些BPF程式類型使用bpfskstorage來抽象套接字對象。這些抽象是通過對象的生命周期來管理的，目的是使BPF程式更加簡單，并且不容易出錯和洩漏。本更新檔主要實作：

概括了bpfskstorage基礎結構，以使其易于實作其他對象的本地存儲
為inode實作本地存儲
使bpf_ {sk，inode} _storage都可用于LSM程式

2.2 tailcalls in BPF subprograms

目前BPF對BPF程式本身的調用和尾部調用是互斥的，但是該更新檔成功讓他們可以同時工作，即讓尾部調用可以和BPF子程式同時工作。該更新檔通過在開始和結束階段丢棄未使用的被調者儲存的push/pop寄存器數值，進而提升AF-XDP的運作速度。其最終結果是提升了15%左右的性能。該更新檔的缺陷在于它将會對利用尾部調用的BPF程式産生負面影響，但是影響不大。總而言之，從長遠來看：利大于弊。

2.3 io_uring: add restrictions to support untrusted applications and guests

該更新檔添加了一些限制條件，進而使不受信任的應用程式和使用者能夠通路iouring。其想法是在操作中添加一些限制（sqe操作碼和标志位，注冊操作碼），這樣能夠允許不受信任的應用和使用者安全的使用iouring隊列。

2.4 Core-sched v6+: kernel protection and hotplug fixes

該更新檔增加系統的安全性，是V6核心排程邏輯的延續。它增加了使用者模式程序和訪客之間系統調用和中斷的隔離。而這是當其他使用者或者訪客使用HT，在HT下安全進入核心模式的關健。該系列更新檔還解決了當選擇下一個task的時候，cpusmtmask改變導緻的CPU熱插拔問題。

該問題的根本原因在于：雖然核心排程避免了使用者模式下的超線程之間的攻擊，但是當某個超線程進入核心時，核心排程邏輯并沒有做任何追蹤處理。這就導緻了MDS和L1TF攻擊在超線程并發執行時有機可乘。該系列更新檔實作了跟蹤進入及退出核心的線程。進而增加了對保護所有syscall和IRQ核心模式條目的支援。
性能測試：sysbench用于測試該更新檔的性能。使用4核8線程的虛拟機并同時運作2個sysbench測試程式。每個sysbench運作4個任務：sysbench --test = cpu --cpu-max-prime = 100000 --num-threads = 4運作。比較以下各種組合的性能結果。以下名額是“每秒事件數”：

條件	結果
Coresched已禁用	sysbench-1 / sysbench-2 => 175.7 / 175.6
啟用Coreched，兩個sysbench都标記追蹤	sysbench-1 / sysbench-2 => 168.8 / 165.6
已啟用Coresched，已标記追蹤sysbench-1，未标記追蹤sysbench-2	sysbench-1 / sysbench-2 => 96.4 / 176.9
關閉	sysbench-1 / sysbench-2 => 97.9 / 98.8

同時标記追蹤兩個sysbench時，性能下降約4％。對于帶标記/未标記的情況，帶标記的情況會受到影響，因為當它進入核心時，它總是會停頓。但這并不比smtoff差。

3. 裝置驅動相關

3.1 Intel Platform Monitoring Technology

英特爾平台監控技術(Intel Platform Monitoring Technology,簡稱PMT)，是一種枚舉和通路硬體監控功能的架構．随着使用者對硬體的遙測技術越來越感興趣，這就要求工程師不僅要弄清楚硬體是如何測量和收集資料的，還要清楚資料如何傳輸并且可視．這些通常都需要特殊工具來實作，這也就要求使用者管理多套不同的工具,以便在其系統上收集不同種類的監視資料．如果在核心驅動裡實作這些功能，就要經常維護，并随着硬體更新而時刻改變．

PMT提供了一種通過硬體不可知架構從裝置發現和讀取遙測資料的解決方案，該架構允許在不需要核心或軟體工具更新檔的情況下對系統進行更新．

PMT定義了幾個功能來支援從硬體收集監控資料，所有這些都可以作為帶有Intel廠商代碼的PCIE指定廠商擴充能力(DVSEC)的單獨執行個體被發現．DVSEC ID唯一．并為每個ID提供BAR偏移，偏移内包括GUID、特性類型、偏移量和長度，以及适用的配置設定，GUID唯一地辨別了螢幕資料的寄存器空間，同時通過xml提供開放出來的寄存器清單．這允許供應商執行固件更新，可以改變映射(例如，添加新的名額)，而不需要對驅動程式或軟體工具進行任何更改．

3.2 Net: add support for threaded NAPI polling

NAPI輪詢(polling)工作方式已被大多數裝置(尤其是 802.11裝置)所支援，但輪詢工作通常被某個cpu 綁定，非常容易引起一些非常繁忙的cpu将大部分時間花在軟中斷/軟中斷上，而一些cpu則是空閑的．

線程化的NAPI基于工作隊列來實作，所有的API幾乎相同，除了用netif_threaded_napi_add代替了原來的netif_napi_add.

使用MT7621進行的測試，同時使用線程化的NAPI +　一個用于tx排程的線程可以将LAN->WLAN吞吐量提高10-50%. 沒有線程化的NAPI的吞吐量非常不一緻，這取決于運作tx排程線程的CPU．通過測試，線程化的NAPI工作更加穩定．

4. 記憶體管理

4.1 memcg: Enable fine-grained per process memory control

Memory Controller（cgroup記憶體控制器）可用于控制和限制任務使用的實體記憶體。如果使用的實體記憶體超過限制，Memory Controller會嘗試回收記憶體。通常，Memory Controler可以将占用的實體記憶體限制在最大值以下。

有時，實體記憶體回收的速率趕不上配置設定的速率。在這種情況下，占用的實體記憶體會持續增加。當達到最大限制或者系統可用記憶體不足時，将調用OOM Killer殺死某些程序，以釋放更多的記憶體。但是通常無法控制殺死哪個程序，OOM Killer會随機殺死程序。殺死一些擁有重要資源，且還沒有釋放資源的程序，可能會在之後引起其它的系統問題。

在記憶體不足時，不希望OOM Killer随機殺死程序的使用者，可以通過prctl(2)使用本更新檔提供的記憶體控制工具。本工具可以在超過記憶體限制時，執行一些緩解措施。

目前支援的緩解措施包括以下内容：

對于配置設定或處理記憶體的某些系統調用傳回ENOMEM
減慢實體記憶體回收被消耗趕上的過程
向程序發送特定信号
殺死程序

4.2 huge vmalloc mappings

在定義了 HAVE_ARCH_HUGE_VMAP 和支援 PMD vmaps的平台，讓vmalloc會先嘗試配置設定PMD大小的頁面，然後在fallback到小的頁面，目前隻支援帶了PAGE_KERNEL參數的配置設定。

作者在POWER9用`git diff`做了測試，顯示TLB misses下降了30倍(59,800 -> 2,100) CPU cycles也減少了0.54%。

當然這個會帶來更多的記憶體浪費，是以加了一個啟動參數nohugevmalloc禁止這個行為。

4.3 Support high-order page bulk allocation

有些特殊場景需要批量的配置設定特定大小的頁，比如需要配置設定4800 * order-4 pages。當有記憶體壓力時是很難配置設定到order-4這樣的連續記憶體頁的，一個辦法是通過CMA的方式，但是CMA有可能會太慢了:
 * 4800 of order-4 * cma_alloc is too slow

這個Patch引入了一個新的函數alloc_pages_bulk()來解決這個問題：

int alloc_pages_bulk(unsigned long start, unsigned long end,                       unsigned int migratetype, gfp_t gfp_mask,                       unsigned int order, unsigned int nr_elem,                       struct page **pages);

5. 檔案系統和Block IO5.1 ext4: add free-space extent based allocator 此patch為ext4檔案系統引入了新的multiblock 配置設定器，即增強版本的空閑塊管理政策，旨在加快系統運作速度和加強可拓展性，減少由于配置設定導緻的瓶頸。此patch基于Kadekodi S. 和Jain S.的論文 "Taking Linux Filesystems to the Space Age: Space Maps in Ext4"。
5.2 virtiofs: Add DAX support這個更新檔系列給virtiofs檔案系統添加了DAX(Direct Access)特性支援。該特性允許客戶機在使用virtiofs檔案系統時繞過客戶機的頁面緩存，同時允許客戶機将主機上的頁面緩存直接映射到客戶機位址空間。
當需要通路一個檔案的頁面時，客戶機會發送一個請求來映射該頁面（在主機的頁面緩存中）到QEMU位址空間中。從客戶機内部看來，這就是一個由virtiofs裝置控制的實體記憶體的一個區域。并且客戶機可以使用DAX直接映射這個實體記憶體區域，進而獲得對主機上的檔案資料的通路。
在非常多的情況下，這樣做可以大大加快通路速度。同時，這樣做還可以節省大量記憶體，因為檔案資料不再需要在客戶機的頁面緩存中儲存備份，并且它可以從主機頁面緩存中直接被通路。該更新檔系列的大部分修改都局限于fuse/virtiofs兩個子產品。但是為了能夠通路共享記憶體區域，對通用DAX基礎架構和virtio也進行一些修改。
5.3 xfs：解決2038年時間戳上限在xfs的原先設計中，inode timestamps 是一個 signed 32-bit 的秒計數器，quota timers 是 unsigned 32-bit 的秒計數器，0 都表示 Unix 的紀元 1970年1月1日。
在這樣的定義下，inode timestamps 可以表示範圍：‍-(2^31-1) (13Dec1901) through (2^31-1) (19Jan2038)quata timers 可以表示時間範圍：0(1Jan1970) through (2^32-1) (7Feb2106).在2038年，xfs 的 inode 時間戳就沒法記錄時間了。為了解決這個問題，更新檔重新設計了時間戳的定義，加寬了計數範圍。更新檔把 inode timestamps 調整為 unsigned 64-bit 類型的納秒計數器，從1901年開始。quota timers 則是 a34-bitunsignedsecond counter right shifted two bits，且 capped at the maximum inode timestamp value。是以，新的 inode 時間戳範圍是：0(13Dec1901) through (2^64-1/ 1e9) (2Jul2486)理論上 quota timers 可以達到0 (1 Jan 1970) through (((2^34-1) + (2^31-1)) & ~3) (16 Jun 2582)考慮到 quota 最大不超過 inode 時間戳，是以 quota timer最大是：max((2^64-1 / 1e9) - (2^31-1), (((2^34-1) + (2^31-1)) & ~3) (2 Jul 2486).5.4 block/bpf：用eBPF實作IO請求的過濾原始的BPF（Berkeley Packet Filter）可用于網絡包的過濾，全新的 eBPF（externed BPF）提供了更多的功能，一方面，它已經為核心追蹤(Kernel Tracing)、應用性能調優/監控、流控(Traffic Control)等領域帶來了激動人心的變革；另一方面，在接口的設計以及易用性上，eBPF 也有了較大的改進。
此更新檔的作者利用eBPF實作了IO請求的過濾，在作者提供的的執行個體中 /samples/bpf/protect_gpt*.c 通過使用IO過濾器阻止寫前34個扇區的形式保護GUID分區表。過濾 IO 的 eBPF 的執行個體代碼如下：SEC("io_filter")int run_filter(struct bpf_io_request *io_req){  if (io_req->sector_start < GPT_SECTORS && (io_req->opf & REQ_OP_MASK) != REQ_OP_READ)    return IO_BLOCK;  else    return IO_ALLOW;}為了實作這功能，更新檔新增了 eBPF program type BPFPROGTYPEIOFILTER 和 attach type BPFBIOSUBMIT。這功能通過 submit_bio() 的 make_generic_requests_check() 檢查 eBPF 程式的傳回來判斷 IO請求是丢棄( IO_BLOCK)還是接納( IO_ALLOC)。5.5 fs：新增支援讀寫的Linux NTFSWindow有幾個廣為流傳的檔案系統，分别是Fat32、NTFS、exFAT，但因為種種原因，在Linux平台上長期以來都沒做到完美支援。Linux在很早之前就支援vfat（fat32）的讀寫了，在前段時間也開源了exFAT的源碼，唯獨Linux上NTFS隻能讀不能完美支援寫資料。終于，支援讀寫的 Linux NTFS 要來了。
如更新檔作者表述的， Thisisfully functional NTFSRead-Writedriver. 這是一個全功能的NTFS。
6. 網絡本月更新兩個方面：MPTCP中引入SYN Cookie功能，增強網路安全性。使BPF可以區分MPTCP的位元組流，并在tcp的header option中引入BPF功能。6.1 在MPTCP中引入SYN Cookie功能MPTCP（MultiPathTCP）是一個還比較年輕的技術,其目的是允許傳輸控制協定（TCP）連接配接使用多個路徑（比如：主機多位址）來最大化信道資源使用。其核心思想是定義一種在兩個主機之間建立連接配接的方式，而不是在兩個接口之間（例如标準TCP）SYN Cookie是對TCP伺服器端的三次握手協定作一些修改，專門用來防範SYN Flood攻擊的一種手段。大概原理是在TCP伺服器收到TCP SYN包并傳回TCP SYN+ACK包時，不配置設定一個專門的資料區，而是根據這個SYN包計算出一個cookie值。在收到TCP ACK包時，TCP伺服器在根據那個cookie值檢查這個TCP ACK包的合法性。如果合法，再配置設定專門的資料區進行處理未來的TCP連接配接。　在引入中面臨着key如何存儲來驗證他正确的問題，本次采用b方案解決：将nonces存儲在某地struct joinentry，用來驗證MPJOIN ACK和對應的socket請求。6.2 BPFBPF區分TCP sockets and MPTCP subflow sockets.
bpf(Berkeley Packet Filter)伯克利包過濾器，其雖然叫伯克利但針對的卻是網絡，目的是為了提供一種過濾包的方法，可以通過使用者空間經過BPF解析後傳給核心。不太熟悉小夥伴可以粗的類比為Thunderbird中的Filter過濾器，去篩選處理郵件。隻是BPF要過濾的不是郵件而是網路位元組流。後來2013年更新後的版本叫做ebpf主要用于兩個領域，一個是核心跟蹤和事件監控，另外一個應用領域是網絡程式設計。由于之前BPFPROGTYPESOCKOPS鈎子上無法區分普通TCP套接字（TCP　sockets）和MPTCP子流套接字（MPTCP subflow sockets),這次送出三個更新檔後，可以對子流（subflow）套接字進行精細控制。區分它允許使用BPF程式在來自同一MPTCP連接配接（套接字标記、TCP擁塞算法等）by BPF programs.bpf-tcp-header-opts:　在之前成功将TCP擁塞控制算法寫入BPF一樣，可以節約時間去測試/釋出新的四種擁塞算法(congestion control algorithm)。現在要把tcp　header option引入到BPF中: 增加了新的BPF的API并用BPFPROGTYPESOCKOPS去分析TCP hearder.搞了一個結構體來包含saved_syn，其中0813a84156 ("bpf: tcp: Allow bpf prog to write and parse TCP header option")是核心patch.
7. 虛拟化和容器7.1 Enable Linux guests on Hyper-V on ARM64該更新檔系列支援将Linux客戶作業系統運作在Arm64架構Hyper-V建立的虛拟機裡。在arch/arm64/hyperv中新增的arm64特定代碼用于Hyper-V虛拟硬體的初始化，包括它的中斷和hypercall機制。現有的用于Hyper-V的VMbus和虛拟裝置的架構無關驅動程式也可以為Arm64平台進行編譯，但也僅僅是可以工作的階段。Hyper-V的相關代碼，隻有在CONFIGHYPERV核心配置選項被打開時，才會被編譯并包含到核心映像和子產品中去。在Arm64架構的Hyper-V虛拟機中運作Linux客戶機需要的工作還有一些地方還在進行中：Arm64架構的Hyper-V目前運作時的頁面大小為4K位元組，但允許客戶機使用16K或者64K位元組大小的頁面。然而，在Hyper-V虛拟裝置的Linux驅動程式中，客戶機系統使用的頁面大小被假設為4K位元組。這個更新檔集為客戶機系統使用更大的頁面先做一些基礎工作，後續會有跟多的更新檔來更新這些驅動程式。Hyper-V vPCI驅動程式（drivers/pci/host/pci-hyperv.c）因為包含有x86/x64特定的代碼，并不能在Arm64平台上編譯。這個驅動将在晚些時候被修複用以使能Arm64上的vPCI裝置。*在一些情況下，來自x86/x64的術語也被帶到了Arm64的代碼中(“MSR”、“TSC”)。Hyper-V沒有使用更通用的術語來替代它們，還是保留使用x86/x64中的術語。這個問題将在Hyper-V 更新TLFS用法時得到解決。7.2 Remove 32-bit Xen PV guest support這個計劃的長期目标是将Xen PV客戶機替換為PVH客戶機。現在該計劃的第一個受害者出現了，是x86_32位PV客戶機，因為這種類型的客戶機現在已經很少使用了。目前Xen在x86上需要64位CPU支援，并且從官方版本2.04開始的Grub2已經能正式支援PVH客戶機。是以已經沒有必要在Linux中繼續支援32位的PV客戶機。另外，Meltdown的緩解措施在32位的PV客戶機上并不可用，是以從安全的角度來看，放棄這種類型的客戶機也是有意義的。（譯注：不同于Arm，Xen在x86上支援以下3種類型的客戶機：PV Guest，HVM和PVH。下圖是這三種類型的客戶機推出時間線。
PV Guest推出的時間最早，它不依賴于硬體的虛拟化支援，客戶機OS通過Xen提供的PV接口完成OS特權操作。HVM伴随着硬體虛拟化技術誕生，客戶機OS可以通過硬體提供的虛拟化支援，透明地完成OS特權操作。但是外設仍然需要依賴于QEMU等emulator進行模拟。PVH是最近幾年推出的，它仍然需要硬體虛拟化技術支援，但不再依賴QEMU進行裝置模拟，而是通過PV driver進行IO操作。PVH具有輕量化高性能的特點，缺點是對舊的OS支援基本沒有。）7.3 HSM driver for ACRN hypervisorACRN是一種Type-1類型的虛拟機管理器軟體棧，它可以直接運作在裸硬體上，廣泛适合于各種物聯網和嵌入式裝置解決方案。通過一個特權Service VM，ACRN實作了一個混合虛拟機管理器架構。Service VM管理User VM的系統資源(如CPU、記憶體等)和I/O裝置。它支援多個User VM，每個虛拟機都可以運作Linux、Android或Windows作業系統。Service VM和User VM都是ACRN的虛拟機。下圖展示了ACRN的架構。ACRN中隻有一個Service VM，它可以運作Linux作業系統。在一個典型的場景，Service VM伴随着ACRN Hypervisor啟動時自動啟動。然後運作在Service VM中的ACRN userspace可以通過與ACRN Hypervisor服務子產品 (HSM，Hypervisor Service Module )通信來啟動/停止User VM。ACRN Hypervisor服務子產品(HSM)類似一個中間件，它允許ACRN userspace和Service VM作業系統核心與ACRN Hypervisor通信并管理不同的User VM。這個中間件層提供以下功能：-向hypervisor發出hypercall來管理User VM:VM /vCPU的管理記憶體的管理裝置透傳中斷注入 -處理User VM發出的I/O請求。-通過HSM 字元裝置導出ioctl接口 -導出函數給核心其它子產品調用 因為ACRN聚焦于嵌入式裝置，是以它也不支援某些特性。比如ACRN不支援虛拟機遷移ACRN不支援CPU遷移 該更新檔向核心添加ACRN Hypervisor服務子產品 (HSM，Hypervisor Service Module )代碼。7.4 mm/virtio-mem: support ZONEMOVABLE在之前引入virtio -mem的時候，ZONEMOVABLE的語義在當時是相當地不明确，這就是為什麼我們需要特别處理ZONEMOVABLE，因為這樣可以防止部分插入的記憶體塊出現在ZONEMOVABLE中。
但是現在，ZONEMOVABLE的語義變得更清楚了(我們在patch#6中對它做了文檔說明)，是以我麼可以開始在ZONEMOVABLE中支援部分插入的記憶體塊，允許部分插入的記憶體塊在ZONE_MOVABLE上線和斷開。這樣可以避免記憶體塊的上線時突然失敗的意外，因為virtio-mem還沒有将它們完全填充完畢。這對測試特别有用，但同時也為virtio-mem的優化鋪平了道路，允許更多記憶體被可靠地斷開。清理hasunmovablepages()和setmigratetypeseparation()兩個函數。在文檔中更好地描述了ZONEMOVABLE是如何與不同類型的不可移動頁面互動的(memory offlining vs. alloccontig_range())。7.5 Support virtio cross-device resources 這個更新檔集是按照連結[1]中的提案實作了VIRTIO跨裝置的資源共享。他将會被用于将VIRTIO資源導入到VIRTIO-VIDEO驅動中。VIRTIO-VIDEO驅動還在讨論中，可以參考連結[2]。連結[3]是正在考慮的在VIRTIO-VIDEO驅動程式中添加支援的更新檔。它正在使用的API是這個更新檔集的v3版本，但是更新它所做的更改相對來說不會太多。這個更新檔集新增了一種dma-bufs，它支援查詢底層virtio對象的UUID，同時支援從virtgpu導出資源。[1] https://markmail.org/thread/2ypjt5cfeu3m6lxu
[2] https://markmail.org/thread/p5d3k566srtdtute
[3] https://markmail.org/thread/j4xlqaaim266qpks7.6 KVM:Add virtualization support of split lock dection 這個更新檔系列的目标是在KVM中添加split lock detection的虛拟化支援。（譯注：split lock是一種記憶體或者總線鎖，一旦一個CPU使用該鎖，其它的CPU或者裝置都無法通路記憶體或者總線）。因為split lock detection的實作是和CPU型号緊耦合的，而虛拟機的CPU型号又是由VMM配置的。是以我們選擇采用半虛拟化的方式來向客戶機暴露并列舉CPU的型号。7.7 KVM: PKS Virtualization support這個RFC更新檔系列引入了KVM對PKS的支援，更新檔中有些定義依賴于PKS核心更新檔。PKS (Protection Keys for Supervisor Pages，特權頁面的保護密鑰)是保護密鑰體系架構的一個擴充特性，用于以支援限制特定線程在特權頁面上的通路權限。（譯注：PKS将核心位址空間中的每個頁面和一個Protection Key關聯起來。Protection Key一共16個，是以核心頁面被劃分為16個區域，每個區域都可以獨立配置權限。修改這些區域的權限政策會比直接修改這些頁面的權限設定會更加高效）PKS的工作原理與現有的PKU(使用者頁面保護)相似。它們都是在系統完成原有的通路權限檢查之後再執行一個額外的檢查。如果通路權限被違反了，則會觸發#PF并且PFEC.PK狀态位将被設定。PKS引入MSR IA32PKRS來管理特權頁面保護密鑰的權限。MSR包含16對ADi和WDi位。每一對ADi/WDi可以将權限通知到整組具有相同PKS密鑰的頁面中，該密鑰被儲存在頁表項的bits[62:59]。目前IA32PKRS并沒有被XSAVES架構支援。這個更新檔集的目的是在KVM中添加PKS的虛拟化支援。它實作了PKS CPUID枚舉，vmentry/vmexit配置，MSR公開，嵌套虛拟化的支援等。目前，PKS還不支援影子頁表。關于PKS的詳細資訊可以在最新的“Intel 64 and IA-32 Architectures Software Developer's Manual”手冊中找到。(END)

複制