。。

assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.edn

@@ -1602,4 +1602,4 @@
                           :page 14},
                :content {:text " transaction semantics on PM"},
                :properties {:color "yellow"}}],
- :extra {:page 14}}
+ :extra {:page 12}}

assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.edn

@@ -2791,4 +2791,4 @@
                           :page 13},
                :content {:text "uses hardware capability pointers (which describe the lower and upper bounds of a memory range) for memory transfer."},
                :properties {:color "yellow"}}],
- :extra {:page 13}}
+ :extra {:page 11}}

journals/2023_05_07.md

@@ -1,5 +1,5 @@
 - DONE Paper2 看完
 	- 废了我差不多一整天才看完
-- TODO 编译器调试
+- DONE 编译器调试
 	- 摆烂了,明天再说
 - 明天又要上课了，无聊的小熊思想，无聊的中午课，还下雨，草

journals/2023_05_08.md

@@ -0,0 +1,7 @@
+- DONE 写一下自我介绍
+- DONE 回顾论文，写个总结
+- TODO 写自我陈述初稿
+- DONE English resume refine
+	- TODO 扫描各种奖状：果酱证书、寻找robocup奖状、CET6扫描、成绩证明扫描
+- IPADS半夜发邮件是真的离谱，不让我好好睡觉了是吧
+- 调编译器浪费了比我预想中更多的时间，文书材料没写完，干

journals/2023_05_09.md

@@ -0,0 +1,3 @@
+- 明天要interview，只能写一天文书了，草
+	- 再不写就要寄了
+	- 姑且是差不多了

journals/2023_05_10.md

@@ -0,0 +1,3 @@
+- TODO 小熊思想读书会报告
+- TODO 跟学长要套磁信
+- TODO 写一会编译器，简单的llir生成

logseq/bak/journals/2023_05_04/2023-05-08T02_32_16.559Z.Desktop.md

@@ -0,0 +1,3 @@
+- TODO Paper1-HTMFS Implementation 看完
+- TODO 模式识别作业提交
+- TODO 写一会编译器

logseq/bak/journals/2023_05_07/2023-05-09T12_39_44.296Z.Desktop.md

@@ -0,0 +1,5 @@
+- DONE Paper2 看完
+	- 废了我差不多一整天才看完
+- TODO 编译器调试
+	- 摆烂了,明天再说
+- 明天又要上课了，无聊的小熊思想，无聊的中午课，还下雨，草

logseq/bak/journals/2023_05_08/2023-05-10T04_11_37.714Z.Desktop.md

@@ -0,0 +1,7 @@
+- TODO 写一下自我介绍
+- TODO 回顾论文，写个总结
+- TODO 写自我陈述初稿
+- DONE English resume refine
+	- TODO 扫描各种奖状：果酱证书、寻找robocup奖状、CET6扫描、成绩证明扫描
+- IPADS半夜发邮件是真的离谱，不让我好好睡觉了是吧
+- 调编译器浪费了比我预想中更多的时间，文书材料没写完，干

logseq/bak/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0/2023-05-08T02_32_16.805Z.Desktop.md

@@ -0,0 +1,240 @@
+file:: [HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf](../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf)
+file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf
+
+- Abstract
+  ls-type:: annotation
+  hl-page:: 2
+  hl-color:: yellow
+  id:: 644b27f5-e3e1-4a24-a507-820e0abbbfd5
+- Introduction
+  ls-type:: annotation
+  hl-page:: 2
+  hl-color:: yellow
+  id:: 644b2866-2f98-49f4-a914-2d1400d47e3b
+	- Earlier FSs optimize for performance, but provide loose consistency guarantees
+	- With the speedup of modern storage devices, strong consistency can ease the pain of software programming.
+	- Strong consistency implies per-request sequential consistency.
+		- atomic modification: inode level locks
+		- Transaction semantics after crash recovery, all-or-none
+	- modern storage devices, PMEM, or non-volatile RAM
+	  hl-page:: 2
+	  ls-type:: annotation
+	  id:: 64511829-234d-45a3-9d1c-f50d60466704
+	  hl-color:: yellow
+		- Problem with existent PM FS: complicated mechanism, write amplification
+	- Previous approaches are limited to atomicity unit of CPU writes.
+	  ls-type:: annotation
+	  hl-page:: 2
+	  hl-color:: yellow
+	  id:: 64511979-cee9-4f46-87ba-6bbfe86bf0a4
+	- Problem with RTM: Block IO abort RTM; PM can be accessed as RAM, but with cache involved, also abort RTM
+	- enhanced asynchronous DRAM refresh (eADR)
+	  hl-page:: 3
+	  ls-type:: annotation
+	  id:: 64511f4c-4338-41ad-9264-263ed5a08bf4
+	  hl-color:: yellow
+		- guarantee the persistence of memory writes once they become globally visible, 
+		  ls-type:: annotation
+		  hl-page:: 3
+		  hl-color:: yellow
+		  id:: 6451204b-d1b8-46ed-8ec9-3a7c2d05244e
+		- eliminate the need for cache flush to sync with PM
+		- See [Detail](https://www.intel.com/content/www/us/en/developer/articles/technical/eadr-new-opportunities-for-persistent-memory-applications.html)
+	- Several challenges with RTM-PM
+	  hl-page:: 3
+	  ls-type:: annotation
+	  id:: 6451205e-7f48-43e8-8704-d221d806cc18
+	  hl-color:: yellow
+		- RTM is small, while FS data transfer are generally large
+		- Some FS operations have long code-path, lengthening RTM section, increasing conflict abort rate
+	- Hardware-assisted Optimistic Persistence
+	  ls-type:: annotation
+	  hl-page:: 3
+	  hl-color:: yellow
+	  id:: 64512109-8ab0-49aa-b6a3-1524df0631ef
+		- eADR, HTM with cooperative locks as fallback
+		- HTMFS, a user-space PM file systems base on ZoFS
+		  ls-type:: annotation
+		  hl-page:: 3
+		  hl-color:: yellow
+		  id:: 64512150-84a0-4839-aef6-48bb872fa776
+- Background and Motivation
+  ls-type:: annotation
+  hl-page:: 3
+  hl-color:: yellow
+  id:: 6451215b-a495-4d6f-9427-f5c0c6685a28
+	- Persistent Memory and PM File Systems
+	  ls-type:: annotation
+	  hl-page:: 4
+	  hl-color:: yellow
+	  id:: 645124e7-37ae-404c-bc83-2ae78628767f
+		- 主要的点就是，PM 是 ==byte-addressable==
+		- Existing PMFS: The only difference would be leveraging atomic instructions to provide small updates up to a single cache line
+		  hl-page:: 4
+		  ls-type:: annotation
+		  id:: 64526ec1-37e2-4891-bba8-eeb07c6e02d3
+		  hl-color:: yellow
+			- 作者认为现有的PMFS没啥创新，在一致性上还是用的旧东西，除了用 PM 提供的 atomic inst 来简化某些原子操作
+	- 2.3 Hardware Transactional Memory
+	  ls-type:: annotation
+	  hl-page:: 4
+	  hl-color:: yellow
+	  id:: 6452709d-6036-4dcd-8821-c106562565fe
+		- RTM的基本用法：把 critical section 用 `xbegin` 和 `xend` 包起来
+		  hl-page:: 4
+		  ls-type:: annotation
+		  id:: 645270e0-2153-4414-8b22-762cfc113c19
+		  hl-color:: yellow
+		- Conflict aborts
+		  hl-page:: 4
+		  ls-type:: annotation
+		  id:: 64527149-e50e-46c8-990f-0465060f9a5a
+		  hl-color:: yellow
+			- 硬件维护trx的 read set 和 write set，如果在提交之前，有别的 core 读 write set 或者写 read set，就会 abort。这些东西都在 cache 里面，维护这些也是用 cache coherence protocol
+		- Capacity aborts. 
+		  ls-type:: annotation
+		  hl-page:: 4
+		  hl-color:: yellow
+		  id:: 645271fa-ff04-4263-a2f2-d1879c1fb857
+			- 受到每个core本地cache比如L1，的大小的限制
+		- Other aborts
+		  hl-page:: 4
+		  ls-type:: annotation
+		  id:: 64527248-77dc-4d32-8a2b-737b7329d2e9
+		  hl-color:: yellow
+			- 不兼容指令，中断（所以打IO显然不行）等东西
+	- 2.4 HTM in PM File Systems
+	  ls-type:: annotation
+	  hl-page:: 4
+	  hl-color:: yellow
+	  id:: 64527270-d6d5-4232-98af-c0212ef47511
+		- HTM的操作是在 cache 里面的，没有持久化保证，除非显式刷到内存/PM里。但是 临界区内不能刷（刷了就abort），临界区之后要是被切走就寄了（除非上锁，不如直接上锁）
+		- Intel 的新东西表示，它可以做到commit到cache里面就能持久化
+- 3 Design
+  ls-type:: annotation
+  hl-page:: 5
+  hl-color:: yellow
+  id:: 6452774e-a951-480a-a890-322d30fe3fd0
+	- 直接把 FS 操作用HTM包起来不现实，因为FS的操作都很长很大
+	- 3.1 HOP
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 645277dc-272c-4479-9d09-3f178cb77a42
+		- 非常自然的想法：把一个操作，或者说trx，拆成小的
+		- 三种操作分类：
+			- Read、Invisible write(内部的东西，比如块分配信息) 、Visible write(应用程序可见的)
+		- 只有 Visible Write 用 HTM 实现，Invisible 和 Read 通过别的机制来实现
+		- （对于一整个FS操作）首先在 RTM 外面完成所需的 read 和 invisible，然后用 RTM 完成 visible，保证它们是 atomic 的。
+		  hl-page:: 5
+		  ls-type:: annotation
+		  id:: 64533b91-7e2b-448b-bb4f-807cc7cb5a77
+		  hl-color:: yellow
+		- RTM外面的部分不保证并发安全，用 sequence count 来解决这个问题。
+		  hl-page:: 5
+		  ls-type:: annotation
+		  id:: 64533cf1-c232-4630-8cf9-88cf4dbfe0c2
+		  hl-color:: yellow
+			- 这东西的原型是 Linux 里面的 `seqlock` 。基本原理可以看这个。 [SeqLock中文博客](http://www.wowotech.net/kernel_synchronization/seqlock.html)。 然后这里的机制大概就是把 writer lock 给换成了 RTM，虽然细节上不是很一样
+			- 在读之前（RTM外）先记录 seqcount，然后进入 RTM 之后进行验证，需要保证在 RTM commit 之前这些 seqcount 都没变。如果有变化，就需要重新回到 RTM 外面的某一点重新读取
+			- 当然如果是 accidental abort，那么只需要重新执行RTM就可以了（就算前面读的数据炸了，反正还是要验证一次的）
+			- 不过有个问题它没说，就是 invisible write，它没有RTM保证不会写冲突啊？不过也有可能，它会保证 invisible 不涉及临界区？？
+	- Discussion of concurrency correctness.
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 6453427e-ce5a-4746-960b-45f9546e8b37
+		- Read-Read显然不冲突
+		- Write-Write 他说potential conflicting write 会被RTM保护起来，不过有可能会live lock掉
+		- Write-Read 也就是如果在RTM里面写入并且commit之前读取，会导致RTM abort
+		- Read-Write 的情况就比较复杂了。作者给了个图，考虑了 T1 读，同时有T2写的例子
+			- T2 在 T1 验证之前写：Valid fail 然后重新读。不过其实是有一个 overlap 的，图里面的第三个B点应该也会 RTM-abort
+			- T2 在 T1 验证之后、RTM commit 之前写：因为读取的数据在 RTM 的 read-set 里面，所有还是会 RTM abort
+- 3.2 File Operations
+  ls-type:: annotation
+  hl-page:: 6
+  hl-color:: yellow
+  id:: 64534050-8459-4719-866e-612b76560e00
+	- 其实看 Figure 3 就行了
+	- 3.2.1 Data Read
+	  ls-type:: annotation
+	  hl-page:: 6
+	  hl-color:: yellow
+	  id:: 64534bc6-4bde-47c6-9fa2-3a085ff59c66
+		- 前面也写了，用 seqcnt 机制来保证读一致性。众所周知，每个文件的inode里面都有block指针，这里给每个指针都配上了一个seqno，读的时候就用这些个东西
+	- 3.2.2 Data Write
+	  ls-type:: annotation
+	  hl-page:: 6
+	  hl-color:: yellow
+	  id:: 64534cee-e35f-4e07-a79d-9185e36b57a2
+		- convert data updates to metadata updates that can be embedded in the RTM transactions.
+		  ls-type:: annotation
+		  hl-page:: 6
+		  hl-color:: yellow
+		  id:: 645357b1-b9ab-456c-87b3-c1047ec5ce59
+		- small writes，直接塞进RTM
+		  hl-page:: 6
+		  ls-type:: annotation
+		  id:: 64535855-08bc-484d-951e-6cf191d5729f
+		  hl-color:: yellow
+		- 大量写入，先把数据写入PM，然后再更新元数据。这时候用的就是block指针了。具体：空间分配是用的DRAM数据；（存疑？然后 shadow page 写文件数据）；最后 RTM 修改 FS 元数据，allocation 的修改这个时候才会被持久化。如果 trx 提交之前炸了，顶多就是写了点垃圾数据到空白位置罢了。
+			- But the blocks may have leaked after a system crash. 没看懂，为啥会leak啊？你的 alloc 数据又没落盘。
+			  hl-stamp:: 1683184901505
+			  hl-page:: 6
+			  ls-type:: annotation
+			  id:: 64535ce3-9927-4e22-b2ed-9c396c3b43f2
+			  hl-color:: red
+			- 不过看上去，它们这边是认为分配一个块是个双向的过程，不仅会在总的freelist里面有记录，block 里面也有一个记录表明它的分配情况？
+	- 3.2.3 Allocation
+	  ls-type:: annotation
+	  hl-page:: 7
+	  hl-color:: yellow
+	  id:: 64534d02-3d6b-4dd4-8d3f-e86767190f08
+		- 首先把已经分配的块放进一个 temporal allocating list 里面 （大概会在 alloc 阶段持久化？），如果commit成功就不管它，如果出事了就把这个里面的块还回去
+		  hl-page:: 7
+		  ls-type:: annotation
+		  id:: 64535d27-c876-4481-856e-8962e5ba9b16
+		  hl-color:: yellow
+		- 在释放块的时候，也会存在中途 crash 的问题。一般是先删掉reference 然后再释放块，如果没释放完，那这个块就leak了。还是有和前面类似的疑问，这东西不是 引用一删就已经整完了吗？
+		- the file system crashes after a reference to a block of data has been removed (when this block of memory has not yet been freed)
+		  ls-type:: annotation
+		  hl-page:: 7
+		  hl-color:: red
+		  id:: 64535f97-b733-4522-a2d1-dbfc8837799e
+		  hl-stamp:: 1683185566331
+- 3.3 Directory Operations
+  ls-type:: annotation
+  hl-page:: 7
+  hl-color:: yellow
+  id:: 64534d0c-9fe2-4817-b510-5d2da7d55dbf
+	- 3.3.1 Path Walk
+	  ls-type:: annotation
+	  hl-page:: 7
+	  hl-color:: yellow
+	  id:: 64534d0f-1882-4633-9cd4-fce9d411aeb9
+	- 3.3.2 Directory Updates
+	  ls-type:: annotation
+	  hl-page:: 7
+	  hl-color:: yellow
+	  id:: 64534d19-b941-4c04-a084-2d8a09d00883
+- 3.4 Other File Types
+  ls-type:: annotation
+  hl-page:: 8
+  hl-color:: yellow
+  id:: 64534d23-1327-40ef-b58e-7c5a01559552
+	- 就写了一个 symlink，但是这玩意就是其他操作的组合罢了，没啥特别的东西
+- 3.5 The Timestamps
+  ls-type:: annotation
+  hl-page:: 8
+  hl-color:: yellow
+  id:: 64534d33-2bfe-4817-a5bd-0cc3534584d7
+- 3.6 The Special Case: Rename
+  ls-type:: annotation
+  hl-page:: 8
+  hl-color:: yellow
+  id:: 64534d37-b14f-4943-92c0-7bb4823fbd50
+- 4 Implementation
+  ls-type:: annotation
+  hl-page:: 9
+  hl-color:: yellow
+  id:: 64534d45-e498-427d-b4ef-74eaf56f7aae

logseq/bak/pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0/2023-05-09T12_39_44.382Z.Desktop.md

@@ -0,0 +1,456 @@
+file:: [HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf](../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf)
+file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf
+
+- Abstract
+  ls-type:: annotation
+  hl-page:: 2
+  hl-color:: yellow
+  id:: 644b27f5-e3e1-4a24-a507-820e0abbbfd5
+- Introduction
+  ls-type:: annotation
+  hl-page:: 2
+  hl-color:: yellow
+  id:: 644b2866-2f98-49f4-a914-2d1400d47e3b
+	- Earlier FSs optimize for performance, but provide loose consistency guarantees
+	- With the speedup of modern storage devices, strong consistency can ease the pain of software programming.
+	- Strong consistency implies per-request sequential consistency.
+		- atomic modification: inode level locks
+		- Transaction semantics after crash recovery, all-or-none
+	- modern storage devices, PMEM, or non-volatile RAM
+	  hl-page:: 2
+	  ls-type:: annotation
+	  id:: 64511829-234d-45a3-9d1c-f50d60466704
+	  hl-color:: yellow
+		- Problem with existent PM FS: complicated mechanism, write amplification
+	- Previous approaches are limited to atomicity unit of CPU writes.
+	  ls-type:: annotation
+	  hl-page:: 2
+	  hl-color:: yellow
+	  id:: 64511979-cee9-4f46-87ba-6bbfe86bf0a4
+	- Problem with RTM: Block IO abort RTM; PM can be accessed as RAM, but with cache involved, also abort RTM
+	- enhanced asynchronous DRAM refresh (eADR)
+	  hl-page:: 3
+	  ls-type:: annotation
+	  id:: 64511f4c-4338-41ad-9264-263ed5a08bf4
+	  hl-color:: yellow
+		- guarantee the persistence of memory writes once they become globally visible, 
+		  ls-type:: annotation
+		  hl-page:: 3
+		  hl-color:: yellow
+		  id:: 6451204b-d1b8-46ed-8ec9-3a7c2d05244e
+		- eliminate the need for cache flush to sync with PM
+		- See [Detail](https://www.intel.com/content/www/us/en/developer/articles/technical/eadr-new-opportunities-for-persistent-memory-applications.html)
+	- Several challenges with RTM-PM
+	  hl-page:: 3
+	  ls-type:: annotation
+	  id:: 6451205e-7f48-43e8-8704-d221d806cc18
+	  hl-color:: yellow
+		- RTM is small, while FS data transfer are generally large
+		- Some FS operations have long code-path, lengthening RTM section, increasing conflict abort rate
+	- Hardware-assisted Optimistic Persistence
+	  ls-type:: annotation
+	  hl-page:: 3
+	  hl-color:: yellow
+	  id:: 64512109-8ab0-49aa-b6a3-1524df0631ef
+		- eADR, HTM with cooperative locks as fallback
+		- HTMFS, a user-space PM file systems base on ZoFS
+		  ls-type:: annotation
+		  hl-page:: 3
+		  hl-color:: yellow
+		  id:: 64512150-84a0-4839-aef6-48bb872fa776
+- Background and Motivation
+  ls-type:: annotation
+  hl-page:: 3
+  hl-color:: yellow
+  id:: 6451215b-a495-4d6f-9427-f5c0c6685a28
+	- Persistent Memory and PM File Systems
+	  ls-type:: annotation
+	  hl-page:: 4
+	  hl-color:: yellow
+	  id:: 645124e7-37ae-404c-bc83-2ae78628767f
+		- 主要的点就是，PM 是 ==byte-addressable==
+		- Existing PMFS: The only difference would be leveraging atomic instructions to provide small updates up to a single cache line
+		  hl-page:: 4
+		  ls-type:: annotation
+		  id:: 64526ec1-37e2-4891-bba8-eeb07c6e02d3
+		  hl-color:: yellow
+			- 作者认为现有的PMFS没啥创新，在一致性上还是用的旧东西，除了用 PM 提供的 atomic inst 来简化某些原子操作
+	- 2.3 Hardware Transactional Memory
+	  ls-type:: annotation
+	  hl-page:: 4
+	  hl-color:: yellow
+	  id:: 6452709d-6036-4dcd-8821-c106562565fe
+		- RTM的基本用法：把 critical section 用 `xbegin` 和 `xend` 包起来
+		  hl-page:: 4
+		  ls-type:: annotation
+		  id:: 645270e0-2153-4414-8b22-762cfc113c19
+		  hl-color:: yellow
+		- Conflict aborts
+		  hl-page:: 4
+		  ls-type:: annotation
+		  id:: 64527149-e50e-46c8-990f-0465060f9a5a
+		  hl-color:: yellow
+			- 硬件维护trx的 read set 和 write set，如果在提交之前，有别的 core 读 write set 或者写 read set，就会 abort。这些东西都在 cache 里面，维护这些也是用 cache coherence protocol
+		- Capacity aborts. 
+		  ls-type:: annotation
+		  hl-page:: 4
+		  hl-color:: yellow
+		  id:: 645271fa-ff04-4263-a2f2-d1879c1fb857
+			- 受到每个core本地cache比如L1，的大小的限制
+		- Other aborts
+		  hl-page:: 4
+		  ls-type:: annotation
+		  id:: 64527248-77dc-4d32-8a2b-737b7329d2e9
+		  hl-color:: yellow
+			- 不兼容指令，中断（所以打IO显然不行）等东西
+	- 2.4 HTM in PM File Systems
+	  ls-type:: annotation
+	  hl-page:: 4
+	  hl-color:: yellow
+	  id:: 64527270-d6d5-4232-98af-c0212ef47511
+		- HTM的操作是在 cache 里面的，没有持久化保证，除非显式刷到内存/PM里。但是 临界区内不能刷（刷了就abort），临界区之后要是被切走就寄了（除非上锁，不如直接上锁）
+		- Intel 的新东西表示，它可以做到commit到cache里面就能持久化
+- 3 Design
+  ls-type:: annotation
+  hl-page:: 5
+  hl-color:: yellow
+  id:: 6452774e-a951-480a-a890-322d30fe3fd0
+	- 直接把 FS 操作用HTM包起来不现实，因为FS的操作都很长很大
+	- 3.1 HOP
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 645277dc-272c-4479-9d09-3f178cb77a42
+		- 非常自然的想法：把一个操作，或者说trx，拆成小的
+		- 三种操作分类：
+			- Read、Invisible write(内部的东西，比如块分配信息) 、Visible write(应用程序可见的)
+		- 只有 Visible Write 用 HTM 实现，Invisible 和 Read 通过别的机制来实现
+		- （对于一整个FS操作）首先在 RTM 外面完成所需的 read 和 invisible，然后用 RTM 完成 visible，保证它们是 atomic 的。
+		  hl-page:: 5
+		  ls-type:: annotation
+		  id:: 64533b91-7e2b-448b-bb4f-807cc7cb5a77
+		  hl-color:: yellow
+		- RTM外面的部分不保证并发安全，用 sequence count 来解决这个问题。
+		  hl-page:: 5
+		  ls-type:: annotation
+		  id:: 64533cf1-c232-4630-8cf9-88cf4dbfe0c2
+		  hl-color:: yellow
+			- 这东西的原型是 Linux 里面的 `seqlock` 。基本原理可以看这个。 [SeqLock中文博客](http://www.wowotech.net/kernel_synchronization/seqlock.html)。 然后这里的机制大概就是把 writer lock 给换成了 RTM，虽然细节上不是很一样
+			- 在读之前（RTM外）先记录 seqcount，然后进入 RTM 之后进行验证，需要保证在 RTM commit 之前这些 seqcount 都没变。如果有变化，就需要重新回到 RTM 外面的某一点重新读取
+			- 当然如果是 accidental abort，那么只需要重新执行RTM就可以了（就算前面读的数据炸了，反正还是要验证一次的）
+			- 不过有个问题它没说，就是 invisible write，它没有RTM保证不会写冲突啊？不过也有可能，它会保证 invisible 不涉及临界区？？
+	- Discussion of concurrency correctness.
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 6453427e-ce5a-4746-960b-45f9546e8b37
+		- Read-Read显然不冲突
+		- Write-Write 他说potential conflicting write 会被RTM保护起来，不过有可能会live lock掉
+		- Write-Read 也就是如果在RTM里面写入并且commit之前读取，会导致RTM abort
+		- Read-Write 的情况就比较复杂了。作者给了个图，考虑了 T1 读，同时有T2写的例子
+			- T2 在 T1 验证之前写：Valid fail 然后重新读。不过其实是有一个 overlap 的，图里面的第三个B点应该也会 RTM-abort
+			- T2 在 T1 验证之后、RTM commit 之前写：因为SeqCnt在 RTM 的 read-set 里面，写操作会修改seqcnt，所有还是会 RTM abort
+- 3.2 File Operations
+  ls-type:: annotation
+  hl-page:: 6
+  hl-color:: yellow
+  id:: 64534050-8459-4719-866e-612b76560e00
+	- 其实看 Figure 3 就行了。首先分配 shadow page，然后写 shadow page，最后用 RTM 更新指针到 shadow 上。
+	- 3.2.1 Data Read
+	  ls-type:: annotation
+	  hl-page:: 6
+	  hl-color:: yellow
+	  id:: 64534bc6-4bde-47c6-9fa2-3a085ff59c66
+		- 前面也写了，用 seqcnt 机制来保证读一致性。众所周知，每个文件的inode里面都有block指针，这里给每个指针都配上了一个seqno，读的时候就用这些个东西
+	- 3.2.2 Data Write
+	  ls-type:: annotation
+	  hl-page:: 6
+	  hl-color:: yellow
+	  id:: 64534cee-e35f-4e07-a79d-9185e36b57a2
+		- convert data updates to metadata updates that can be embedded in the RTM transactions.
+		  ls-type:: annotation
+		  hl-page:: 6
+		  hl-color:: yellow
+		  id:: 645357b1-b9ab-456c-87b3-c1047ec5ce59
+		- small writes，直接塞进RTM
+		  hl-page:: 6
+		  ls-type:: annotation
+		  id:: 64535855-08bc-484d-951e-6cf191d5729f
+		  hl-color:: yellow
+		- 大量写入，先把数据写入PM，然后再更新元数据。这时候用的就是block指针了。具体：空间分配是用的DRAM数据；（存疑？然后 shadow page 写文件数据）；最后 RTM 修改 FS 元数据，allocation 的修改这个时候才会被持久化。如果 trx 提交之前炸了，顶多就是写了点垃圾数据到空白位置罢了。
+			- But the blocks may have leaked after a system crash. 没看懂，为啥会leak啊？你的 alloc 数据又没落盘。
+			  hl-stamp:: 1683184901505
+			  hl-page:: 6
+			  ls-type:: annotation
+			  id:: 64535ce3-9927-4e22-b2ed-9c396c3b43f2
+			  hl-color:: red
+			- 不过看上去，它们这边是认为分配一个块是个双向的过程，不仅会在总的freelist里面有记录，block 里面也有一个记录表明它的分配情况？
+	- 3.2.3 Allocation
+	  ls-type:: annotation
+	  hl-page:: 7
+	  hl-color:: yellow
+	  id:: 64534d02-3d6b-4dd4-8d3f-e86767190f08
+		- 首先把已经分配的块放进一个 temporal allocating list 里面 （大概会在 alloc 阶段持久化？），如果commit成功就不管它，如果出事了就把这个里面的块还回去
+		  hl-page:: 7
+		  ls-type:: annotation
+		  id:: 64535d27-c876-4481-856e-8962e5ba9b16
+		  hl-color:: yellow
+		- 在释放块的时候，也会存在中途 crash 的问题。一般是先删掉reference 然后再释放块，如果没释放完，那这个块就leak了。还是有和前面类似的疑问，这东西不是 引用一删就已经整完了吗？
+		- the file system crashes after a reference to a block of data has been removed (when this block of memory has not yet been freed)
+		  ls-type:: annotation
+		  hl-page:: 7
+		  hl-color:: red
+		  id:: 64535f97-b733-4522-a2d1-dbfc8837799e
+		  hl-stamp:: 1683185566331
+		- 反正感觉讲的就挺矛盾的。。。也有可能是没理解清楚？
+- 3.3 Directory Operations
+  ls-type:: annotation
+  hl-page:: 7
+  hl-color:: yellow
+  id:: 64534d0c-9fe2-4817-b510-5d2da7d55dbf
+	- Figure 5 描述了目录的形式。相较于简单的UNIX FS，它在目录的inode和entry之间加了一个hash table。DirInode 指向一个 block 里面放了一个hash tab， 然后每个hash tab entry指向一组dir entries，里面才是每个目录的名字、inode
+	- 3.3.1 Path Walk
+	  ls-type:: annotation
+	  hl-page:: 7
+	  hl-color:: yellow
+	  id:: 64534d0f-1882-4633-9cd4-fce9d411aeb9
+		- 记录每个遍历到的entry的seqcnt，然后在RTM里面验证这些家伙
+		  hl-page:: 7
+		  ls-type:: annotation
+		  id:: 645385d6-70be-41ba-8697-f6bf49608834
+		  hl-color:: yellow
+	- 3.3.2 Directory Updates
+	  ls-type:: annotation
+	  hl-page:: 7
+	  hl-color:: yellow
+	  id:: 64534d19-b941-4c04-a084-2d8a09d00883
+		- 不对目录的inode加锁。
+		- 插入或删除Dir Entry 的时候，更新 hash tab 的 bucket 的 Bseq，这样就不会冲突了（甚至还能增加一些并行性能，如果hash到不同的bucket）。不过好像直接用正在修改的目录的 Dseq 好像也可以？
+- 3.4 Other File Types
+  ls-type:: annotation
+  hl-page:: 8
+  hl-color:: yellow
+  id:: 64534d23-1327-40ef-b58e-7c5a01559552
+	- 就写了一个 symlink，但是这玩意就是其他操作的组合罢了，没啥特别的东西
+- 3.5 The Timestamps
+  ls-type:: annotation
+  hl-page:: 8
+  hl-color:: yellow
+  id:: 64534d33-2bfe-4817-a5bd-0cc3534584d7
+	- 三种 timestamp： Access（访问）, Modified（修改内容）, Changed（修改元数据）
+	- timestamp应该和其他操作写在同一个 trx 里面
+	- Here we observe that placing accesses and modifications to critical variables at the end of a transaction significantly reduces the probability of an abort due to conflicts.
+	  ls-type:: annotation
+	  hl-page:: 8
+	  hl-color:: yellow
+	  id:: 6453916b-6fc1-4e3a-8e54-5d6c3767cf45
+		- 不知道为啥
+- 3.6 The Special Case: Rename
+  ls-type:: annotation
+  hl-page:: 8
+  hl-color:: yellow
+  id:: 64534d37-b14f-4943-92c0-7bb4823fbd50
+	- `unlink` 和 `rmdir` 都只能删掉叶子节点，比如 rm 只能删掉空目录，所以比较简单
+	- `rename` 操作没有限制，会涉及到两条路径，要删一个entry再加一条entry
+		- 可能的死锁问题，两个并发的rename操作，涉及相同的两个目录，然后互相锁了一个。可以通过比较 lock 变量地址的方法来决定上锁顺序以避免这个问题
+		- 目录环问题。paper里面的例子讲的很清楚，只锁两个父目录没用，虽然不会出现一致性问题，但是会出环。所以一般会用个全局锁
+		- 不过 HOP 不会有这个问题。因为它的目录依赖都被记录了，只要有任何一级目录被修改，都会 validation fail 然后重来。在RTM里面会进行：validate、 removing 和 adding 三个操作
+- 4 Implementation
+  ls-type:: annotation
+  hl-page:: 9
+  hl-color:: yellow
+  id:: 64534d45-e498-427d-b4ef-74eaf56f7aae
+	- 基于 ZoFS 实现，不过我也不知道它是个啥。它分成两部分，内核里面一部分，还有用户空间的 Library。
+		- 坏家伙，ZoFS 是也是这帮人自己写的
+	- 根据权限不同，把整个 FS tree 分成不同的 zone
+	- Figure 7： HTMFS 分为 KernFS （大概是直接白嫖了 ZoFS 的）和自己写的 LibFS。两者通过接口 `Coffer_enlarge/shrink` 进行交互，好像 KernFS 就是个分配管理器。。。。
+	- 4.1 KernFS
+	  ls-type:: annotation
+	  hl-page:: 9
+	  hl-color:: yellow
+	  id:: 64539829-6f23-49fe-a860-ffa78b301acd
+		- 维护整个 FS 所有 zone 的信息，以及 PM 页面的属性
+		- 每个 zone 有一个 root page 存元数据
+		- 用一个 persistent 哈希表存所有的 zone ，映射 zone 的路径前缀 -> zone 的 root page 的相对地址
+			- User space 的请求发过来是路径，然后 KernFS 通过这个表获得 zone
+		- 两级分配：把很多的 pages 分给 zone，然后每个 zone 在细分管理这些 page。
+			- KernFS 会管理这些页面的分配状态。用两个全局的红黑树来管理 free 和 allocated 的空间，这两颗 RBT 在DRAM里面， crash 之后需要重建
+- 4.2 LibFS
+  ls-type:: annotation
+  hl-page:: 9
+  hl-color:: yellow
+  id:: 6453982f-f915-40ae-a87b-f94a89af4369
+	- 维护每个 zone 内部的 data metadata，比如文件、目录
+	- 前面的 Design 都是在这里实现的
+	- KernFS 用 free list 管理分配，如果某个 zone 打 syscall 请求空间， KernFS 返回一个 free list 。为了不修改 kernel side， LibFS 要转换这个 list 使得能够被 HTMFS 识别
+	- Fallback path ：先 retry 再上锁（+ RTM 更新）最后 journaling
+	  hl-page:: 9
+	  ls-type:: annotation
+	  id:: 6453a07f-ca96-4a02-9cc3-1c4cb460ebee
+	  hl-color:: yellow
+		- 因为有这个 fallback ，所以在 RTM 里面要先检查是不是别的进程给 lock 了，如果 lock 了就直接中止 RTM 转而去抢 lock 。
+		- 总结一个 RTM trick ：如果要检查什么东西，放进 RTM 里面检查，因为会加进 read-set ，这样别人改了的话就会 abort
+- 4.3 Prevent RTM abort
+  ls-type:: annotation
+  hl-page:: 9
+  hl-color:: yellow
+  id:: 64539833-3b3c-451b-b550-6d33dd8ac106
+	- 主要原因是 page fault ，但是没法搞，所以事先 access 一下，然后再进 RTM，这样就不太容易在 RTM 里面炸了
+	- 偶然的 abort，直接 retry ；如果次数太多，那么就 fallback
+		- fallback 策略：先上锁，把 conflict abort 的可能性消除，然后再执行 HOP （或者说是RTM，就是前面的机制，这里只是不让他们冲突了）来保证崩溃一致性
+	- 其他原因，什么指令问题，不过那个链接挂了
+- 5 Evaluation
+  ls-type:: annotation
+  hl-page:: 10
+  hl-color:: yellow
+  id:: 64551435-bee3-456a-93f1-8fce14cd5771
+	- Performance comparison with weak consistency FS
+	- Application performance
+	- How HTM improve FS
+- 5.2 Micro-benchmarks
+  ls-type:: annotation
+  hl-page:: 10
+  hl-color:: yellow
+  id:: 64551575-289f-4811-9a35-863dbe0a0eb7
+	- Data overwrite, low contention, first 4K of ==Different files==
+		- `rep-mov` 和 `sse-mov` 之间的性能差距导致 HTMFS 比 ZoFS 要慢
+		- 在这种情况下，cache hit rate 很高。而 `rep-mov` 的性能在这种情况下 `sse2-mov` 要好。其他的没有这种问题（因为hit）
+	- Data overwrite, medium contention. ==Shared file, different blocks==
+		- lock-free 让 HTMFS 在这种情况下显著领先，而其他的FS会随着并发数上升而性能下降
+		- Scalability
+	- Data append, low contention
+		- most writes miss the cache
+		  ls-type:: annotation
+		  hl-page:: 10
+		  hl-color:: yellow
+		  id:: 64551b25-e4a7-401d-b143-3d4857c4e294
+			- NOVA 用了 non-temporal write 和 per-core allocator，绕过 cache 直接写 PM
+			- HTMFS 正常先写 cache 然后再同步到 PM，miss 的时候要先读再写（占两倍带宽），导致 PM 的带宽不够了
+			- 如果给 HTMFS 换上 NT write ，性能会好很多
+			- 好像后面还是会寄掉，说是撞到了 bandwidth 上限
+	- Data read, low contention. Different file, a block
+		- all file systems scale nearly linearly （虽然HTMFS更高）
+		  hl-page:: 10
+		  ls-type:: annotation
+		  id:: 64551cee-971e-4759-be45-8f96ebe50a4e
+		  hl-color:: yellow
+		- medium, high contention 的情况 (shared file/shared block) 差不多
+	- Metadata create. Create files in different directories
+		- 到后面不 scale 了，写入带宽不够
+		- NOVA 在低带宽的情况下比 HTMFS 好，因为 ZoFS 用 0 表示不存在的页面，因此在创建的时候要大量写0，而 ZoFS 没有很好的 crash consistency，如果仅用文件大小表示页面存在性，可能会导致 index 和 size 不一致
+		- 如果 HTMFS 删掉这个步骤（有一致性保证）变成 NZ 版本，会变快跟NOVA差不多
+	- Metadata create, medium. Create files in same directory.
+		- HTMFS scales best. 因为用的锁策略是 hash bucket
+		- NZ 效果前期会更好，因为消除了一些 memset
+	- Metadata rename, low. Rename in different dirs
+		- All scale linearly, HTMFS best
+	- Metadata rename, medium. Move to shared dir
+		- HTMFS much better, fine-grained OCC
+	- Abort rate.
+	  ls-type:: annotation
+	  hl-page:: 11
+	  hl-color:: yellow
+	  id:: 64551ead-5c0e-4978-99f6-f9156e8ed99e
+		- 基本上没什么，到 Fall back 的就更少了
+	- The latency of the fallback path.
+	  ls-type:: annotation
+	  hl-page:: 11
+	  hl-color:: yellow
+	  id:: 64551ef9-fa99-4c2d-8dd5-e0343042aeb6
+		- 3 paths, HTM, fallback, journal
+		- Data write 的延迟，fallback 略高于 HTM，但是 journal 远高于 两倍的HTM
+			- 这是因为 HTM 不是直接写 PM 的，而是写 cache （然后由 eADR 保证断电后 cache 的东西会存进 PM）。如果用直接写 PM 的方法，那么 journal 差不多是两倍
+		- Metadata write 的延迟几种差不多
+	- The performance under high abort rate. Write same file same block
+	  ls-type:: annotation
+	  hl-page:: 12
+	  hl-color:: yellow
+	  id:: 645522ec-84b5-4c1e-b029-90cb01e58587
+		- 测试的是 fallback 的性能，如果不是由于 memcpy 指令，HTMFS 的性能最好
+- 5.3 Macro-benchmarks
+  ls-type:: annotation
+  hl-page:: 12
+  hl-color:: yellow
+  id:: 64551608-5fe1-4f1b-adfc-6d13f0226c41
+	- 用了两个综合测试。都是小文件读写
+	- Webproxy 是读为主，几种好像都差不多，HTMFS和ZoFS稍微高一点
+	- Varmail 是读写差不多，metadata操作多，HTMFS比较好
+- 5.4 Crash Consistency Correctness
+  ls-type:: annotation
+  hl-page:: 12
+  hl-color:: yellow
+  id:: 6455164b-8ba7-4bef-b5d8-bb59aca3db00
+	- 论文里面写了一个例子。给一个 4KB 的 全a文件写8KB的b字符。
+		- 先分配一个4K空页
+		- fill 0-4l
+		- fill 4k-8k
+		- 把4K页更新进file index
+		- 更新文件大小和修改时间
+	- 参考状态是 all-or-nothing，也就是要么4K的a；要么8K的b同时修改时间更新、freelist减少
+	- 在表里面，展示了1之后crash、2之后crash、5中间crash三种 crash injection
+- 5.5 Application Benchmarks
+  ls-type:: annotation
+  hl-page:: 12
+  hl-color:: yellow
+  id:: 64551652-fb9f-4e40-863f-96e5e3b40ef7
+	- SQLite + TPC-C
+		- 测吞吐量
+		- HTMFS/ZoFS(相当于是HTMFS的弱一致版本)性能最好，而且HTMFS相对于ZoFS的性能损失较小
+		- NOVA的强一致和弱一致版本之间的差距较大
+	- LevelDB
+		- 测延时
+			- NOVA的写延时要比HTMFS好，而读要差一些
+			- HTMFS和ZoFS性能几乎一致，而NOVA的弱一致版本则在写性能上有较大差距，说明一致性代价较大
+- 6 Discussion
+  ls-type:: annotation
+  hl-page:: 13
+  hl-color:: yellow
+  id:: 6455165b-d35d-4532-beeb-320e353e49ce
+	- 6.1 Other File System Features
+	  ls-type:: annotation
+	  hl-page:: 13
+	  hl-color:: yellow
+	  id:: 64552664-0fc7-426a-bfea-94d9833ef8a8
+		- Compression, Deduplication, Checksum
+		- 这些操作基本上都没有对基本的FS操作提出特殊的要求
+	- 6.2 HOP in Key-Value Stores
+	  ls-type:: annotation
+	  hl-page:: 14
+	  hl-color:: yellow
+	  id:: 645526bd-e94d-4728-8180-2fcdacffc711
+		- HOP 机制可以迁移到 KV 数据库上
+- 7 Related Work
+  ls-type:: annotation
+  hl-page:: 14
+  hl-color:: yellow
+  id:: 645516e6-8343-4d4e-9f2c-f6c13d13687d
+	- Persistent Transactions.
+	  ls-type:: annotation
+	  hl-page:: 14
+	  hl-color:: yellow
+	  id:: 64552bd5-b559-4a64-b2e5-053111a4ebdd
+		- transaction semantics on PM, software programming, user-space
+		  hl-page:: 14
+		  ls-type:: annotation
+		  id:: 64552bf8-10f4-43e8-a07b-b5a2525d1428
+		  hl-color:: yellow
+		- 也有HTM硬件设计的东西（在eADR之前）
+	- System Transactions and Transactional FS.
+	  ls-type:: annotation
+	  hl-page:: 14
+	  hl-color:: yellow
+	  id:: 64552acd-0001-4ec1-8fc5-59187f8cfc3d
+		- 在OS里面用使用 HTM trx
+		- FS 提供 事务 接口（而HTMFS只是用事务来实现POSIX而已）
+	- HTM-assisted OCC
+	  ls-type:: annotation
+	  hl-page:: 14
+	  hl-color:: yellow
+	  id:: 64552b13-6de1-4f6c-9513-8dccdbe11371
+		- 在数据库上用HTM来提供并发性能，也有用切片的方法适应长程操作的研究
+	- Page fault in RTM.
+	  ls-type:: annotation
+	  hl-page:: 14
+	  hl-color:: yellow
+	  id:: 64552b5a-d18e-443e-b77c-9b4700aedfea
+		- 前期的工作解决了该问题，通过修改RTM硬件来识别PF

logseq/bak/pages/hls__XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0/2023-05-10T04_11_37.721Z.Desktop.md

@@ -0,0 +1,741 @@
+file:: [XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf](../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf)
+file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf
+
+- ABSTRACT
+  ls-type:: annotation
+  hl-page:: 1
+  hl-color:: yellow
+  id:: 644b281a-d7fa-4163-8e75-a39d74215bfa
+	- Motivation: resurgent interest in microkernel, mobile devices
+	- 微内核需要很多的 IPC 来保持隔离性，但是IPC 操作很慢。
+		- seL4 single way fast path - 468 cycles; Fuchsia - over 10k round-trip
+		- 相对于宏内核而言，性能差很多
+	- 宏内核也有 IPC 性能问题
+	  hl-page:: 1
+	  ls-type:: annotation
+	  id:: 645656b2-93db-4a0b-913a-1a3887c51e83
+	  hl-color:: yellow
+		- Android application & user-level services
+		- Android Binder 机制：
+			- 一般而言，IPC （比如管道）要先 copy to kernel buffer 再 copy from kernel buffer
+			- Binder 的原理是用内存映射，两个进程映射到同一个 kernel buffer 上面，这样 sender 把数据放进去之后，receiver 就能直接用了
+	- 两个主要的耗时：1) domain switching, and 2) message copying
+	  hl-page:: 1
+	  ls-type:: annotation
+	  id:: 645657b7-afa3-47b8-af22-420c1b276d2e
+	  hl-color:: yellow
+		- 上下文切换有很多指令的overhead
+		- 共享内存有安全问题，TOCTTOU
+		- 页表重映射会导致TLB 大量miss
+	- Previous work
+	  ls-type:: annotation
+	  hl-page:: 2
+	  hl-color:: yellow
+	  id:: 645658e6-082b-4c9c-90f1-cf172fe91328
+		- Software 还是要 trap
+		- Hardware 用 tagged memory 代替页表来减少 switch 的耗时，但是内核要大改
+	- The design has four goals:
+	  ls-type:: annotation
+	  hl-page:: 2
+	  hl-color:: yellow
+	  id:: 645658a9-a477-47cf-bad2-7a5b4bd91683
+		- 不 trap、0拷贝、kernel 小改、hardware 小改
+	- new primitive contains three parts
+	  ls-type:: annotation
+	  hl-page:: 2
+	  hl-color:: yellow
+	  id:: 645658bc-32e3-476b-a1b1-0f3540268e3f
+		- new hardware-aware abstraction, x-entry
+		  ls-type:: annotation
+		  hl-page:: 2
+		  hl-color:: yellow
+		  id:: 64565a96-6cd8-467c-a29a-bd6414a4e138
+			- xcall-cap, for access control
+			  ls-type:: annotation
+			  hl-page:: 2
+			  hl-color:: yellow
+			  id:: 64565aab-ff63-4b68-95c9-e3cb9643c9d7
+		- 新指令使得IPC不用陷入内核
+		  hl-page:: 2
+		  ls-type:: annotation
+		  id:: 64565abb-3c48-4bdd-89ad-7ef0a424bcbc
+		  hl-color:: yellow
+		- new address-space mapping mechanism, relay-seg, for zero-copying message passing
+		  hl-page:: 2
+		  ls-type:: annotation
+		  id:: 64565ae6-b80f-4f0b-b738-fc79efc17aeb
+		  hl-color:: yellow
+			- ownership transfer for TOCTOU, no TLB flush, handover in invoking chain
+	- synchronous IPC
+	  ls-type:: annotation
+	  hl-page:: 2
+	  hl-color:: yellow
+	  id:: 64565b4b-aa86-4c99-a02a-9fff0d9d0dd0
+		- 解决了低 throughput 和难用的多线程模型
+		  hl-page:: 2
+		  ls-type:: annotation
+		  id:: 64565b70-e31c-4e24-8b1f-3511313cc0f4
+		  hl-color:: yellow
+		- the migrating thread model
+		  hl-page:: 2
+		  ls-type:: annotation
+		  id:: 64565b7c-f2d8-49fe-b6a6-8fdc275c1e75
+		  hl-color:: yellow
+- 2 MOTIVATION
+  ls-type:: annotation
+  hl-page:: 2
+  hl-color:: yellow
+  id:: 64565a29-7ced-4d34-8580-fe584783a35b
+	- 2.1 IPC Performance is Still Critical
+	  ls-type:: annotation
+	  hl-page:: 2
+	  hl-color:: yellow
+	  id:: 64565d37-df65-4458-b1f2-838473637201
+		- 测试：YCSB（workload generator for benchmarking KV stores）， seL4，SQLite3
+		- IPC 占用了 20-40% 的时间
+		- IPC 过程中，大概一半的时间在复制数据，当然对于短IPC，大部分时间在 ctx switch（这个时间基本上是固定的）
+	- 2.2 Deconstructing IPC
+	  ls-type:: annotation
+	  hl-page:: 3
+	  hl-color:: yellow
+	  id:: 64565e5f-50d5-4cc6-b9ae-e8451556bb24
+		- two paths of IPC in seL4
+		  hl-page:: 3
+		  ls-type:: annotation
+		  id:: 64565e70-647b-4f21-aaae-d94476a15c2f
+		  hl-color:: yellow
+			- Fast Path and Slow Path， slow 相较于 fast 是它允许调度和中断
+		- Trap & Restore
+		  hl-page:: 3
+		  ls-type:: annotation
+		  id:: 64565ed3-701f-4502-bed8-028aefdb26df
+		  hl-color:: yellow
+			- Caller trap to kernel, kernel restore to callee
+			- 切换是为了隔离，而隔离是因为假设进程之间的 untrust
+				- 可以考虑让 IPC 的两边手动管理这个切换的过程以减少开销
+				- 类似于什么，拥有不同地址空间的多线程？乐
+		- IPC Logic: major task is checking
+		  hl-page:: 3
+		  ls-type:: annotation
+		  id:: 64565f91-f8a0-4a82-9d9e-74097c36b04f
+		  hl-color:: yellow
+			- seL4 用 `capability` 管理资源
+			- The kernel first fetches the caller's capability and checks its validity
+			  hl-page:: 3
+			  ls-type:: annotation
+			  id:: 645665f4-2ade-401d-8959-13ad94c0aaa2
+			  hl-color:: yellow
+			- 然后决定 slow/fast path
+				- caller/callee: have different priorities, on different cores
+				- message size: register-size, buffer-size
+			- 硬件实现部分的 checking 逻辑。
+		- Process Switch
+		  ls-type:: annotation
+		  hl-page:: 3
+		  hl-color:: yellow
+		  id:: 64565f99-ea28-4791-9a09-92fea39fabd8
+			- 切换到 callee， 需要操作调度队列、修改进程状态、传递msg 以及设置 AS
+			- To make the callee have the capability to reply, a reply_cap is added into the callee thread
+			  ls-type:: annotation
+			  hl-page:: 3
+			  hl-color:: yellow
+			  id:: 64566730-0b70-4cac-a6d6-97144d9d3462
+			- 这个过程中的内存访问可能会导致 cache 和 TLB miss
+		- Message Transfer
+		  ls-type:: annotation
+		  hl-page:: 3
+		  hl-color:: yellow
+		  id:: 64565f9d-4bb9-49e9-b070-85e8b71706e0
+			- 3 ways according to message length
+				- 小于 register size ： 在 process switch 的时候复制
+				- 小于 IPC buffer size：用 slow path 复制
+				- 共享内存
+					- 如果直接共享内存，会导致安全和一致性问题。所以一般还是会复制一次，性能垃圾
+			- The message transfer dominates the IPC cycles when the message size is large.
+			  ls-type:: annotation
+			  hl-page:: 3
+			  hl-color:: yellow
+			  id:: 6456684a-d557-4679-8747-044e6dfd7d04
+- 3 DESIGN
+  ls-type:: annotation
+  hl-page:: 3
+  hl-color:: yellow
+  id:: 64565fad-b594-408c-b404-4f04469c4fef
+- 3.1 Design Overview
+  ls-type:: annotation
+  hl-page:: 3
+  hl-color:: yellow
+  id:: 64565fb7-e274-465f-bf50-20dba1c8fde9
+	- User-level Cross Process Call
+	  ls-type:: annotation
+	  hl-page:: 3
+	  hl-color:: yellow
+	  id:: 6456687d-1f7b-4918-942f-78a3c66bdad3
+		- 有很多的 `x-entry` 记录可 IPC 的 procedure，然后有一个ID作为它在表里面的 Index
+		  hl-page:: 3
+		  ls-type:: annotation
+		  id:: 645668e1-ad08-4f89-b860-5fcbd4c57764
+		  hl-color:: yellow
+		- 全局的 `x-entry-table` ，配套一个 `x-entry-table-register` 存基地址、和 `x-entry-table-size` 当界限
+		- `xcall-cap` 规定了每个 `x-entry` 的 IPC capabilities，这个东西是通过一个 capability bitmap 来做的
+		- `xcall #reg` 和 `xret` 指令
+	- Lightweight Message Transfer `relay-seg` 机制
+	  ls-type:: annotation
+	  hl-page:: 4
+	  hl-color:: yellow
+	  id:: 64566b0b-9fd9-474f-aeea-aa032fbca2d5
+		- 一个 `relay-seg` 是一块 ==物理连续== 的内存
+		- 内存地址翻译通过新的 reg `seg-reg` 完成，同时`seg-reg`在 caller 和 callee 之间传递，因此 callee 可以直接访问
+			- OS 需要保证这块物理地址不会被常规的页表映射占用
+			- 因为没有了页表，也就不存在 TLB miss 带来的损失
+	- XPC Programming Model
+	  ls-type:: annotation
+	  hl-page:: 4
+	  hl-color:: yellow
+	  id:: 64566c7e-7f1d-4cdc-86af-6f1705582814
+		- Both Capability & Page table
+		- 代码的例子说是，server 注册 `xpc_register( handler, handler_thread, max_xpc_ctx)`，然后 handler `xpc_return()`， client 先用 `alloc_relay()`构造参数再调用 `xpc_call(server_ID, xpc_arg)`。
+			- ~~不是很理解的是，它这里为了支持多个同时调用，给开了个线程？~~
+				- 大概指的是后面的 C-Stack 机制，不过这也是纯纯的猜
+- 3.2 XPC Engine
+  ls-type:: annotation
+  hl-page:: 4
+  hl-color:: yellow
+  id:: 64565fbe-0166-4201-9078-60168c1045c3
+  collapsed:: true
+	- xcall
+	  ls-type:: annotation
+	  hl-page:: 4
+	  hl-color:: yellow
+	  id:: 64567422-a004-4862-a497-c7ef75be73aa
+		- check caller's xcall-cap, reading `xcall-cap-bitmap[#reg]`
+		- load target `x-entry`, check valid bit
+		- push `linkage-record` with necessary info for ret, to `link-stack` (per-thread stack)
+		- load new page table pointer, set PC to `x-entry` 's entrance, with caller's `xcall-cap-reg` copied to some GPR for identification
+	- xret
+	  ls-type:: annotation
+	  hl-page:: 4
+	  hl-color:: yellow
+	  id:: 64567428-20ea-4554-ad8f-042aad00449d
+		- pop a *linkage-record* and return, with assistance of the popped data, and valid-bit checked
+	- xcall-cap
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 645677fd-f9ea-4b7f-9fa3-50a136bc524f
+		- a per-thread bitmap, each index `i` indicating whether this thread is permitted to call `x-entry[i]`
+		- with its memory region pointed by `xcall-cap-reg`
+	- Link Stack
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 64567819-b985-4543-80da-acf416609a79
+		- a per-thread stack, only accessible by kernel
+		- not saving GPR
+		- a principle that `linkage-record` should maintain information which can not be recovered by user-space.
+		  hl-page:: 5
+		  ls-type:: annotation
+		  id:: 6456796a-9354-48f9-b050-d0c052537225
+		  hl-color:: yellow
+		- A lazy write optimization, context-switching while saving record
+	- XPC Engine Cache
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 6456781d-cbb0-4e2e-b396-04edfa67801e
+		- pre-fetch `x-entry`
+		- software-managed cache
+		- hl-page:: 5
+		  ls-type:: annotation
+		  id:: 64567a42-2b36-4ed5-8505-01f574d5740a
+		  hl-color:: yellow
+		  1. IPC has high temporal locality (for a single thread); 
+		  2. IPC is predictable.
+- 3.3 Relay Segment
+  ls-type:: annotation
+  hl-page:: 5
+  hl-color:: yellow
+  id:: 64565fc3-b632-4cb5-949e-3f96d9ce5f2f
+	- relay-seg
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 64567cca-6189-4008-a36e-f04ddfcdbd8c
+		- add a register `seg-reg` = `VA | PA | Len | Perm`
+		- prior to TLB, direct-map VA to PA (contiguous physical memory)
+		- `relay-seg` 指的是一块内存，而 `seg-reg` 表示的是一个映射
+	- seg-mask
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 64567cc7-b245-4d66-8d32-6c9dec52f0d7
+		- 设计者不希望用户程序直接修改 `seg-reg` 的映射，因此加了一个`seg-mask` 用来把当前进程的 `seg-reg` 切出来一部分再传递
+		- 主要是用来 invoking chain 的，可能是作者认为这种情况比较常见吧
+	- Multiple relay-segs
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 64567ccf-8fae-49c0-af3d-6082254bf2dd
+		- per-process memory region called `seg-list` managed by OS kernel, `seg-list-reg`
+		  hl-page:: 5
+		  ls-type:: annotation
+		  id:: 6457060d-d314-4136-a9e8-c26babc7888d
+		  hl-color:: yellow
+		- `swapseg #reg` 指令用来更换当前的 `seg-reg` `#reg` 是目标在 `seg-list` 里面的下标；当然也可以用来 invalidate （指定无效的ID）
+	- Ownership of relay-seg
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 64570676-1f3f-43ef-a16b-77fda80832b8
+		- kernel （可能是通过调度器？）保证每个 `relay-seg` 任意时刻只能在一个CPU core 上运行，也就是 owned by one thread
+			- 反正 paper 里面没写这东西咋实现的
+		- 说是能够防止 TOCTOU，大概是防止了别人瞎改 `relay-seg` 的内容吧
+	- Return a relay-seg
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 64570679-5acf-4701-b718-f1d3b22d3df7
+		- 硬件保证 `seg-reg` 在 `xret` 的时候和存在 `linkage-record` 里面的是一致的
+		- 奇妙的安全检查机制
+	- emmm，它好像没说怎么创建这些东西的接口？
+- 4 IMPLEMENTATION
+  ls-type:: annotation
+  hl-page:: 5
+  hl-color:: yellow
+  id:: 6457122f-9508-4e29-828e-55c40dbcbfbc
+- 4.1 Integration into RocketChip
+  ls-type:: annotation
+  hl-page:: 5
+  hl-color:: yellow
+  id:: 64571250-753f-4f6c-b402-926ef4594c06
+	- XPC Engine 
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 64571300-8f9d-4e88-83c9-5b37f125f5ab
+		- Implemented as a unit of a RochetChip core
+		- 新加的寄存器通过 CSR 实现，用`csrr/csrw` 读写
+		- **3 new instructions** are sent to the XPC engine in Execution stage. XPC engine checks the validity of an IPC and returns the callee information to the pipeline.
+		  hl-page:: 5
+		  ls-type:: annotation
+		  id:: 645743fe-eb6b-423d-9d5a-cbc3b7df928c
+		  hl-color:: yellow
+		- 加了5个 exception
+		- cache 只有一个 entry 且通过软件进行管理。 prefetch 通过 `xcall`  negative ID 的方式实现
+	- XPC Management
+	  ls-type:: annotation
+	  hl-page:: 5
+	  hl-color:: yellow
+	  id:: 645744ef-f6e9-492c-b177-d863c5d6d847
+		- 4 XPC objects
+			- global `x-entry-table`; pet-thread `link stack`; per-thread  `x-call-cap` bitmap; per-address-space `relay segment list`
+		- 在系统启动的时候，kernel 会分配一个1024项的`x-entry-table`；而创建线程的时候，会分配8K的 `link stack` 和128B的`cap-bitmap`以及4K的`seg-list`
+			- During a context switch, the kernel saves and restores the per-thread objects.
+			  hl-page:: 6
+			  ls-type:: annotation
+			  id:: 6457467f-aedf-4029-ad71-b82f62aef329
+			  hl-color:: yellow
+				- 认真的吗，只是存寄存器吧。。。
+			- 不过如果 entry-table 要是扩大的话，是不是cap-bitmap也要跟着扩大。。。
+- 4.2 Support for Microkernels
+  ls-type:: annotation
+  hl-page:: 6
+  hl-color:: yellow
+  id:: 64571268-b744-43ab-9e30-12ae6f2451a4
+	- Capability
+	  ls-type:: annotation
+	  hl-page:: 6
+	  hl-color:: yellow
+	  id:: 6457475b-0571-4108-b314-2538d8da6ca9
+		- kernel 里面实现一个新的 `grant-cap`，用来管理 thread 是否能向其他 thread grant capability
+		  hl-page:: 6
+		  ls-type:: annotation
+		  id:: 645748ff-d344-4e9c-960f-c87244307900
+		  hl-color:: yellow
+		- kernel 管理每个 thread 的 `grant-cap-list`，所有这个线程注册的 x-entry 都会有一个对应的条目在这个里面，说明当前线程能够把这个 x-entry 的访问权 grant 出去
+	- Split Thread State
+	  hl-page:: 6
+	  ls-type:: annotation
+	  id:: 64574760-c162-414f-a629-7bff2dbeb240
+	  hl-color:: yellow
+		- 因为 x-call 切换线程不需要经过内核，因此 kernel 不知道线程已经切换了，当前的线程会被ntr，要是中途来个 page fault 就直接去世了
+		- separate the kernel-maintained thread state into two parts: scheduling state and runtime state
+		  ls-type:: annotation
+		  hl-page:: 6
+		  hl-color:: yellow
+		  id:: 64574e12-9654-4679-855c-b5ad8d6d2341
+			- scheduling state: kernel stack, priority, time slice -- sched to other thread
+			- runtime state: address space, capabilities -- serve this thread
+			- 每个线程 bind 一个 scheduling state，但是可以有多个 runtime state。kernel 可以通过 per-thread `xcall-cap-reg`来判断 runtime state，因为这玩意在 xcall 的时候会被更新
+	- Per-invocation C-Stack
+	  ls-type:: annotation
+	  hl-page:: 6
+	  hl-color:: yellow
+	  id:: 64574769-7ecc-49a5-9a7f-33de410ed641
+		- 支持一个 `x-entry` 同时被调用
+		- library 提供 per-invoke XPC context，包括 execution stack (C-stack) 和 local data
+		- 注册 x-entry 的时候会提前创建这些 context
+		- 在调用的时候用一个 trampoline 来选择可用的context、切换C-stack、保存local data，以及返回的时候重载数据
+		- 作者提到了 DoS 攻击的可能性，什么恶意进程疯狂调用来占满所有的context。
+			- XPC allows each server to adopt specific policies to limit the invocation from clients
+			  ls-type:: annotation
+			  hl-page:: 6
+			  hl-color:: yellow
+			  id:: 64575485-dcce-4bb6-bc9a-1f89f5f33a9d
+			- ((645796d4-5e4b-41ea-be08-6545fc8c26a6))
+	- Application Termination
+	  ls-type:: annotation
+	  hl-page:: 6
+	  hl-color:: yellow
+	  id:: 6457476d-bc89-4bab-8b7e-b00e332a8c60
+		- 考虑 invoking chain A->B->C 上中间进程B突然挂掉了，后续的进程C可能会返回到已经终止的进程
+		- 在一个进程B终止的时候，kernel 检查所有的`linkage stack` 然后 invalidate 所有属于这个进程B的 entry。这样后续进程C返回的时候，就会触发 `linkage invalid exception`，由 kernel 负责 pop 这个 linkage record 并返回到更先前的进程A
+			- ？进程的回收也是个问题，难不成等所有的 linkage 全 pop 完了才回收吗
+		- 扫描所有的 linkage 效率太低，一个优化：可以在 B 终止的时候清空B的页表而不扫描所有的 linkage stack，这样返回的时候就会有 page fault 陷入 kernel 了
+- 4.3 Support for Android Binder
+  ls-type:: annotation
+  hl-page:: 7
+  hl-color:: yellow
+  id:: 64571271-ee10-47f9-8c6e-97a7211b7c94
+	- 修改了下层的 Binder driver 和中间框架，上层API保持兼容
+	- Binder transaction
+	  ls-type:: annotation
+	  hl-page:: 7
+	  hl-color:: yellow
+	  id:: 645760b0-3819-4dbc-af65-e5edef87061b
+		- client 有一个 method code 用来指定 remote method
+		- client Binder object 调用 `transcat()` 进入 Binder driver，把 userspace buffer 复制到 kernel buffer，然后切到 server 在把 kernel buffer 复制到 server 的 userspace buffer。
+			- 2 copies，2 switches
+		- server Binder object 收到后执行 handler `onTransact()`
+		- 最后通过 driver reply 回去
+	- XPC 实现
+	  ls-type:: annotation
+	  hl-page:: 7
+	  hl-color:: yellow
+	  id:: 64576c77-d72b-4ade-b85a-2d8e94ba606e
+		- 用 Binder driver 管理 xcall-cap 和 x-entry table
+		- server 通过 Binder 注册的时候，framework 会 ioctl Binder driver 来新建 x-entry
+		- client 请求服务的时候，framework 需要 ioctl Binder driver 来设置 xcall-cap
+		- client 调用的时候，framework 直接用 xcall 指令并用 relay-reg 来传递 marshalled data
+		- Linux Kernel 需要作修改来解决前述的线程管理问题 ((64574760-c162-414f-a629-7bff2dbeb240))
+	- Ashmem: Anonymous Shared Memory
+	  hl-page:: 7
+	  ls-type:: annotation
+	  id:: 64576a2a-af0d-40e5-8f4b-3cc5010056bb
+	  hl-color:: yellow
+		- file-based interface，可以通过文件描述符和其他进程共享内存
+			- In Android Binder, processes can share fd of an ashmem through Binder driver.
+			  hl-page:: 7
+			  ls-type:: annotation
+			  id:: 64576ae1-5b66-4d2a-9915-60e3505ef738
+			  hl-color:: yellow
+		- XPC 实现 ashmem
+			- 分配：用 Binder driver 分配一个 relay-seg
+			- map: allocate VA and set `seg-reg`
+			- transfer: passing `seg-reg` in the framework during `xcall`
+			- 存在问题：因为前述的实现中，只有一个 `seg-reg`，因此如果想要同时用多块 ashmem，就只能通过 page fault 或者 `swapreg` 指令来切换 `seg-reg` 来实现
+				- 加个cache？感觉会变成新的TLB了
+			- 好处是不需要拷贝两次了
+- 4.4 Handover along Calling Chain
+  ls-type:: annotation
+  hl-page:: 7
+  hl-color:: yellow
+  id:: 64571276-8880-47f4-addd-b03d3057b7bf
+	- Message Size Negotiation
+	  ls-type:: annotation
+	  hl-page:: 7
+	  hl-color:: yellow
+	  id:: 64576204-098c-4a39-8ba5-9c6811c8b5d7
+		- 为了避免在后续调用中空间不够用，可以在一开始申请 relay-reg 的时候就预留一部分空间
+		- 这就需要 invoking chain 上的所有进程协商一个大小
+			- 不过感觉实现起来也，不是很高效的样子（除非大小是固定的，就跟RTOS一样），就看怎么设计权衡了
+	- Message Shrink
+	  ls-type:: annotation
+	  hl-page:: 7
+	  hl-color:: yellow
+	  id:: 645763ab-7182-4d43-abc6-2e351ecfd599
+		- 用 seg-mask 实现只传递一部分的 message 给 next level on the chain
+	- Segment Revocation
+	  ls-type:: annotation
+	  hl-page:: 8
+	  hl-color:: yellow
+	  id:: 645763f1-9fe6-4c34-9392-e03a8b70ddb9
+		- 进程终止的时候 kernel 扫描它的 seg-list 然后把有 caller 的 relay-reg 还回去，如果是自己申请的就回收
+- 5 EVALUATION
+  ls-type:: annotation
+  hl-page:: 8
+  hl-color:: yellow
+  id:: 6457127a-7663-4375-9e93-f43ed6c06976
+	- 5.2 Microbenchmark
+	  hl-page:: 8
+	  ls-type:: annotation
+	  id:: 64576ea8-1038-44f5-a703-78a40e714b38
+	  hl-color:: yellow
+		- Config
+			- Full-Ctx (save/restore full context), Partial-Ctx
+			- +Tagged TLB, +NonBlock Link Stack, +XPC Engine Cache
+			- 在一次调用中，主要有3部分开销
+				- 如果没开 TLB 优化，TLB miss 会占一部分
+				- trampoline, 保存上下文的时间
+				- xcall logic，主要包括 Linkage stack 和取 seg-reg 的时间，可以通过 nonblock 和 xpc cache 优化
+		- In the following evaluation, XPC will use “Full-Cxt” with “Nonblocking Link Stack” optimizations, to ensure the fairness of the comparison.
+		  ls-type:: annotation
+		  hl-page:: 8
+		  hl-color:: blue
+		  id:: 6457741f-f4e3-47d4-894c-f70936ceb646
+		- One-way Call 这里统计应该是从 client 调用 request 开始到 server 收到 onRequest
+		  hl-page:: 8
+		  ls-type:: annotation
+		  id:: 64577417-b2ff-4ba9-93ca-9b1a2e2cad5b
+		  hl-color:: yellow
+			- 由于 XPC 不需要拷贝，所以开销很低
+			- 如果是普通的 seL4，耗时会随着消息长度而增长。
+				- 从它的图上看，slow path (32-120Byte) 的耗时甚至比 shared memory(128Byte) 要长
+		- Multi-core IPC
+		  ls-type:: annotation
+		  hl-page:: 8
+		  hl-color:: yellow
+		  id:: 6457750c-0dc6-4bb8-b7a5-d6e7bf0c8846
+			- 这个cross core和same core完全一样，对照组延时就直接起飞了，好怪啊。他说是因为它的 migrating thread model 和它的优秀的locality
+				- 不过，TLB你说是因为你用 seg-reg 给替代了倒也合理，cache 换核心了必然要寄掉的啊（难道是L2？）
+				- 好像也，能理解？毕竟ICache/ITLB miss无论单核多核都是必要的，DCache/DTLB 因为不拷贝所以两种都不miss，然后那些个检查本来都是要miss一遍的。seL4因为跨核心了，所以必然是用slow path，外加因为跨核心导致的各种miss
+			- Moreover, a client can easily scale itself by creating several worker threads on different cores and pull the server to run on these cores.
+			  ls-type:: annotation
+			  hl-page:: 9
+			  hl-color:: yellow
+			  id:: 6457788c-f190-455c-ab53-4c3fc77899ba
+		- Other Instructions
+		  ls-type:: annotation
+		  hl-page:: 9
+		  hl-color:: yellow
+		  id:: 6457776f-ef59-41ff-b236-d2a010eb8250
+			- 就，测了测 `xcall/xret/swapreg` 这些指令的周期，主要是访存的时延
+	- 5.3 OS Services
+	  ls-type:: annotation
+	  hl-page:: 9
+	  hl-color:: yellow
+	  id:: 64576ff6-bfd7-4dfa-952b-fcb3b1e82d1f
+		- File System
+		  ls-type:: annotation
+		  hl-page:: 9
+		  hl-color:: yellow
+		  id:: 64577b2d-646d-4b0b-a5b0-ccc79d9e24e2
+			- In microkernels, a file system usually includes two servers, a file system server and a block device server
+			  ls-type:: annotation
+			  hl-page:: 9
+			  hl-color:: blue
+			  id:: 64577dca-1183-4b1c-ba74-a107ff1d3f56
+			  hl-stamp:: 1683455439580
+				- 测试用了一个 Log-structured FS 和一个 ramdisk device
+			- 对于写操作效果比较好，因为涉及到许多要拷贝很多数据的IPC
+		- Network
+		  ls-type:: annotation
+		  hl-page:: 9
+		  hl-color:: yellow
+		  id:: 64577b31-ad0a-4dd2-969c-03e960791649
+			- Microkernel systems usually have two servers for network: one network stack server (including all network protocols) and one network device server.
+			  ls-type:: annotation
+			  hl-page:: 9
+			  hl-color:: blue
+			  id:: 64577e7c-2b07-4986-acc6-bb7248cf9aad
+				- 测试移植了一个协议栈和一个 loopback driver device
+			- 到后面数据量大了，加速效果会降低，因为IPC的数量被摊平了（data get batched）
+	- 5.4 Applications
+	  ls-type:: annotation
+	  hl-page:: 9
+	  hl-color:: yellow
+	  id:: 64577000-b38c-449a-ab4b-038569490568
+		- SQLite3: YCSB-A and YCSB-F gain the most improvement because they have ==a lot of write/update== operations which will trigger ==frequent file access==. YSCB-C has minimal improvement since it is a ==read-only workload== and Sqlite3 has an ==in-memory cache== that can handle the read request well.
+		  hl-page:: 9
+		  ls-type:: annotation
+		  id:: 64577f97-4e63-431b-bd09-1d6eea865836
+		  hl-color:: yellow
+		- Web Server: Most of the benefit comes from ==handover optimization==. Since in multi-server cases, the message will be transferred multiple times.
+		  hl-page:: 9
+		  ls-type:: annotation
+		  id:: 64577ffb-c30d-411c-bdf0-cc172f291786
+		  hl-color:: yellow
+	- 5.5 Android Binder
+	  ls-type:: annotation
+	  hl-page:: 9
+	  hl-color:: yellow
+	  id:: 64577010-66d9-43ef-b304-846fb028414a
+		- 测试了在 WM 和 Compositor 之间的 IPC，两种方法 buffer 和 ashmem
+		- buffer 大小受限，因此只测了小数据；ashmem在小数据的情况下和buffer差不多
+			- ashmem在大数据的情况下的优化倍率就比较小了
+		- 同时测试了只用 relay-seg 而不用 xcall 的实现，在小数据的情况下自然是不如全套实现，大数据下差不多，因为这时候的优化主要都来自于zero-copy
+	- 5.6 Generality
+	  ls-type:: annotation
+	  hl-page:: 10
+	  hl-color:: yellow
+	  id:: 64577019-21ad-4ff1-b8a5-77f0be884b2c
+		- 用了一个周期精确的模拟器来模拟一个 in-order ARMv8-A
+			- use microOps to implement the functionalities of XPC engine
+			  ls-type:: annotation
+			  hl-page:: 10
+			  hl-color:: yellow
+			  id:: 64578330-b7bb-418d-b9a4-5b7e997f6b45
+			- 没有 cache 和 nonblocking 优化
+		- 因为seL4没有支持，甚至还搞了个 instruction trace 出来。。。
+		- 然后这模拟器还没有 TLB flush cost，甚至还专门用个什么 barrier 来模拟它
+		- 提升自然是有的，只不过比较抽象
+	- 5.7 Hardware Costs
+	  ls-type:: annotation
+	  hl-page:: 11
+	  hl-color:: yellow
+	  id:: 64577026-3083-4275-99e1-afa698407303
+		- 其实还行，也就多用了三四百个FF和LUT。不过我觉得就算用 verilog 重写一遍也不见得能优化多少
+- 6 DISCUSSION
+  ls-type:: annotation
+  hl-page:: 11
+  hl-color:: yellow
+  id:: 6457128a-0799-4b0f-aef7-1dca6ef6fdec
+	- 6.1 Security Analysis
+	  ls-type:: annotation
+	  hl-page:: 11
+	  hl-color:: yellow
+	  id:: 645783e4-939f-44c2-ad4f-ba6547483686
+		- XPC Authentication and Identification
+		  ls-type:: annotation
+		  hl-page:: 11
+		  hl-color:: yellow
+		  id:: 64579586-3e38-494b-9d6c-a070c776bc22
+			- xcall 指令有 xcall-cap 检查, 需要从具有对应的 grant-cap 的 server 那里请求, 类似于 nameserver
+			- server 可以通过 `xcall-cap-reg` 来获知调用者, 也是一种鉴权方法
+		- Defending TOCTTOU Attacks
+		  ls-type:: annotation
+		  hl-page:: 11
+		  hl-color:: yellow
+		  id:: 6457958b-9c34-4b6e-9728-779866f4dd6f
+			- 保证 relay-seg 同一时间只能由一个 thread 持有 ((64570676-1f3f-43ef-a16b-77fda80832b8))
+			- kernel 保证 relay-seg 映射的地址和其他地址不重叠, 因此也不会被瞎改
+		- Fault Isolation
+		  ls-type:: annotation
+		  hl-page:: 11
+		  hl-color:: yellow
+		  id:: 645796cd-b37a-4f2b-a19c-9b48c0614a91
+			- 由于 ((6457476d-bc89-4bab-8b7e-b00e332a8c60)) 和 ((645763f1-9fe6-4c34-9392-e03a8b70ddb9)), caller 和 callee 不会相互影响
+			- XPC 提供了 timeout 机制防止 callee 把 caller 给 hang 掉
+		- Defending DoS Attacks
+		  ls-type:: annotation
+		  hl-page:: 11
+		  hl-color:: yellow
+		  id:: 645796d4-5e4b-41ea-be08-6545fc8c26a6
+			- create a lot of relay-seg which requires many continuous physical memory, which may trigger external fragmentation
+			  hl-page:: 11
+			  ls-type:: annotation
+			  id:: 64579853-231a-4d42-aea1-c5679a27126c
+			  hl-color:: yellow
+				- XPC通过将 `relay-seg`塞进进程的私有地址来解决这个问题, 至少不会让整个 OS 炸掉
+			- 至于耗光 context 的问题, XPC 用 credit system 来解决, 也就是检查 caller 是否有足够的 credits
+		- Timing Attacks
+		  ls-type:: annotation
+		  hl-page:: 11
+		  hl-color:: yellow
+		  id:: 645796da-4e3d-4dfb-b772-a0dcf97f6698
+			- 为啥? 类似于 meltdown 那种吗, 没想明白
+	- 6.2 Further Optimizations
+	  ls-type:: annotation
+	  hl-page:: 11
+	  hl-color:: yellow
+	  id:: 645783e8-7a78-4fd5-8d3a-9edd46cd164d
+		- Scalable xcall-cap
+		  ls-type:: annotation
+		  hl-page:: 11
+		  hl-color:: yellow
+		  id:: 64579af6-4b18-4be9-ad30-752d2e45e0b1
+			- 因为bitmap大小是固定的
+			- 可以考虑用 radix-tree, 但是访存延时会增加
+		- Relay Page Table
+		  ls-type:: annotation
+		  hl-page:: 11
+		  hl-color:: yellow
+		  id:: 64579b27-3285-445e-afb7-0ffb806f686d
+			- 现在的 relay-seg 必须物理连续
+			- 可以用不同的页表来实现这个事情
+			- 但是 granularity 会变大, 而且ownership转移会有问题???
+				- 猜测是涉及到页表的加载切换
+- 7 RELATED WORK
+  ls-type:: annotation
+  hl-page:: 11
+  hl-color:: yellow
+  id:: 6457128f-abd3-476a-8103-2bd4ac1a8dab
+	- 7.1 Optimizations on Domain Switch
+	  ls-type:: annotation
+	  hl-page:: 11
+	  hl-color:: yellow
+	  id:: 645784ba-bf63-40e7-adca-1215a1f22ac7
+		- Software
+			- use caller's thread to run callee's code in callee's address space
+			  hl-page:: 11
+			  ls-type:: annotation
+			  id:: 64579dee-7496-4b47-8efa-cab30ba4ceb8
+			  hl-color:: yellow
+				- PPC(protected procedure call) and migrating thread
+			- L4的direct process switch可以减少切换代价并降低调度频率
+		- Hardware
+			- domain的概念不再是process或者是AS,而是用不同ID标识/隔离的执行单元.
+			- domain switch的时候不再需要trap,而是可以直接切ID就行了
+				- 虽然我也不知道这时候怎么搞隔离
+			- 多个domain可以共享地址空间,还能再省一笔
+			- 但是这种方法会导致软件需要大改,可移植性很差
+			- 也有 hybrid 方法, 或者用硬件虚拟化来做
+	- 7.2 Optimizations on Message Passing
+	  ls-type:: annotation
+	  hl-page:: 12
+	  hl-color:: yellow
+	  id:: 645784c3-7513-49a5-b7da-12e5d1e14455
+		- 软件
+			- 老老实实复制两遍
+			- 地址空间重映射,L4把待传递的消息的地址重映射到只有kernel能访问的地址上,这样就省下来一次拷贝到kernel的过程
+				- 不过remapping也还是有不小的overhead
+		- 硬件
+			- a hybrid memory granting mechanism combined with permission list and capability registers. Pass capability register pass memory region
+			  hl-page:: 13
+			  ls-type:: annotation
+			  id:: 6457a7cb-c723-4243-99ef-be1475d258d2
+			  hl-color:: yellow
+				- 感觉和本文差不多? 虽说没有针对TOCTOU做防御,但是本片也不过是kernel保证一下唯一性罢了
+			- uses hardware capability pointers (which describe the lower and upper bounds of a memory range)
+			  hl-page:: 13
+			  ls-type:: annotation
+			  id:: 6457a852-cf47-4a31-924e-e7f8be729b61
+			  hl-color:: yellow
+				- 问题在于他是single address space with tagged memory
+			- use new hardware PLB (protection look-aside buffer) to decouple the permission from the address space translation
+			  ls-type:: annotation
+			  hl-page:: 13
+			  hl-color:: yellow
+			  id:: 6457a77f-0f05-4e78-b41b-b7cf0ba8fc9d
+				- 看上去是个可以做remapping的硬件
+			- 用DTU,一种类似于DMA的东西,但是对于小数据而言overhead太大
+			- 用什么 queue-based hardware accelerators to optimize cross-core communication
+			  hl-page:: 13
+			  ls-type:: annotation
+			  id:: 6457a742-4c8d-4393-81ad-1648a830bc24
+			  hl-color:: yellow
+	- 7.3 Other Related Work
+	  ls-type:: annotation
+	  hl-page:: 13
+	  hl-color:: yellow
+	  id:: 645784c7-9b11-43e1-9c64-80ba30ebdacb
+		- Architectural Support for OS Performance
+		  ls-type:: annotation
+		  hl-page:: 13
+		  hl-color:: yellow
+		  id:: 6457a4d4-08ea-4d2d-ac6d-050a8fc5302b
+		- Shared Memory for IPC
+		  ls-type:: annotation
+		  hl-page:: 13
+		  hl-color:: yellow
+		  id:: 6457a4d8-2fec-4600-b1ae-0bcadc3a3237
+		- Asynchronous IPC
+		  ls-type:: annotation
+		  hl-page:: 13
+		  hl-color:: yellow
+		  id:: 6457a4da-cf42-47db-bf8a-e37415d6750f
+		- Global Address Space Systems
+		  ls-type:: annotation
+		  hl-page:: 13
+		  hl-color:: yellow
+		  id:: 6457a4e2-c501-4f4e-94ef-6fd1783856f4

pages/hls__HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.md

@@ -1,6 +1,20 @@
 file:: [HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf](../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf)
 file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871_0.pdf
 
+- 总结
+	- 硬件条件：PM可以像DRAM一样读写、eADR可以保证RTM提交后的持久化
+	- 动机：现有的基于PM的FS依然在用老旧的一致性方法，复杂而低效；HTM是个好东西，但是有容量、指令类型、冲突等限制
+	- 设计思路：
+		- HOP：把FS操作拆解成小块，关键数据写入塞进RTM里面；大块的数据写入用 shadow page + 指针更新实现；读取用 sequence number 和RTM内验证来保证一致性。
+		- HTMFS：
+			- 文件：文件组织还是INODE+指针，只不过块指针附上了seqno；写入的时候先写shadow page，然后在RTM内更新元数据；块分配主要解决leak问题，通过一个临时freelist记录分配但未提交的块，块回收采用类似的方法。
+			- 目录：目录组织用的是INODE->Hash-table->Entry-Block这样的结构，hash-bucket和entry-item上分别附加了bseq和dseq。读取目录的时候，记录每一级的dseq并验证；修改目录的时候，插入用bseq验证，其他的好像用dseq，全部在RTM里面执行写入。
+	- 实现过程：基于 ZoFS 来做，分为KernFS和LibFS两个部分。KernFS主要就是个分配管理器，把页面外包给LibFS；LibFS具体实现HTMFS，并通过KernFS请求和返还空间。还有 Fallback path 和 abort prevention 策略
+	- 性能：
+		- memcpy指令导致的性能问题、分配清空memset导致的问题、PM的带宽限制导致并发数增加到一定程度之后就不再scale
+		- lock-free、hash-bucket、以及fine-grained 并发控制使得HTMFS性能和scalability不错
+		- 正常情况下 abort 不是很多，高abort-rate下fallback path 的性能也还不错
+		- 对比了保证一致性带来的代价，性能下降不明显
 - Abstract
   ls-type:: annotation
   hl-page:: 2
@@ -11,7 +25,8 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871
   hl-page:: 2
   hl-color:: yellow
   id:: 644b2866-2f98-49f4-a914-2d1400d47e3b
-	- Earlier FSs optimize for performance, but provide loose consistency guarantees
+  collapsed:: true
+	- 早期的FS主要优化性能，但是没啥一致性保证
 	- With the speedup of modern storage devices, strong consistency can ease the pain of software programming.
 	- Strong consistency implies per-request sequential consistency.
 		- atomic modification: inode level locks
@@ -63,6 +78,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871
   hl-page:: 3
   hl-color:: yellow
   id:: 6451215b-a495-4d6f-9427-f5c0c6685a28
+  collapsed:: true
 	- Persistent Memory and PM File Systems
 	  ls-type:: annotation
 	  hl-page:: 4
@@ -123,7 +139,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871
 	  id:: 645277dc-272c-4479-9d09-3f178cb77a42
 		- 非常自然的想法：把一个操作，或者说trx，拆成小的
 		- 三种操作分类：
-			- Read、Invisible write(内部的东西，比如块分配信息) 、Visible write(应用程序可见的)
+			- Read、Invisible write(内部的东西，比如块分配信息) 、Visible write(应用程序可见的，文件大小、修改日期之类的)
 		- 只有 Visible Write 用 HTM 实现，Invisible 和 Read 通过别的机制来实现
 		- （对于一整个FS操作）首先在 RTM 外面完成所需的 read 和 invisible，然后用 RTM 完成 visible，保证它们是 atomic 的。
 		  hl-page:: 5
@@ -184,7 +200,8 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871
 			  ls-type:: annotation
 			  id:: 64535ce3-9927-4e22-b2ed-9c396c3b43f2
 			  hl-color:: red
-			- 不过看上去，它们这边是认为分配一个块是个双向的过程，不仅会在总的freelist里面有记录，block 里面也有一个记录表明它的分配情况？
+			- 猜测1：它们认为分配一个块是个双向的过程，不仅会在总的freelist里面有记录，block 里面也有一个记录表明它的分配情况？
+			- 猜测2：alloc信息会先写到PM里面，从下面的Allocation一节好像也是基于这个假设，但是这和它前面说的 allocation 在DRAM里面的描述又冲突了
 	- 3.2.3 Allocation
 	  ls-type:: annotation
 	  hl-page:: 7
@@ -260,6 +277,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871
   hl-page:: 9
   hl-color:: yellow
   id:: 64534d45-e498-427d-b4ef-74eaf56f7aae
+  collapsed:: true
 	- 基于 ZoFS 实现，不过我也不知道它是个啥。它分成两部分，内核里面一部分，还有用户空间的 Library。
 		- 坏家伙，ZoFS 是也是这帮人自己写的
 	- 根据权限不同，把整个 FS tree 分成不同的 zone
@@ -280,6 +298,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871
   hl-page:: 9
   hl-color:: yellow
   id:: 6453982f-f915-40ae-a87b-f94a89af4369
+  collapsed:: true
 	- 维护每个 zone 内部的 data metadata，比如文件、目录
 	- 前面的 Design 都是在这里实现的
 	- KernFS 用 free list 管理分配，如果某个 zone 打 syscall 请求空间， KernFS 返回一个 free list 。为了不修改 kernel side， LibFS 要转换这个 list 使得能够被 HTMFS 识别
@@ -295,6 +314,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871
   hl-page:: 9
   hl-color:: yellow
   id:: 64539833-3b3c-451b-b550-6d33dd8ac106
+  collapsed:: true
 	- 主要原因是 page fault ，但是没法搞，所以事先 access 一下，然后再进 RTM，这样就不太容易在 RTM 里面炸了
 	- 偶然的 abort，直接 retry ；如果次数太多，那么就 fallback
 		- fallback 策略：先上锁，把 conflict abort 的可能性消除，然后再执行 HOP （或者说是RTM，就是前面的机制，这里只是不让他们冲突了）来保证崩溃一致性
@@ -304,6 +324,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871
   hl-page:: 10
   hl-color:: yellow
   id:: 64551435-bee3-456a-93f1-8fce14cd5771
+  collapsed:: true
 	- Performance comparison with weak consistency FS
 	- Application performance
 	- How HTM improve FS
@@ -380,6 +401,7 @@ file-path:: ../assets/HTMFS_Strong_Consistency_Comes_for_Free_with_1682647018871
   hl-page:: 12
   hl-color:: yellow
   id:: 6455164b-8ba7-4bef-b5d8-bb59aca3db00
+  collapsed:: true
 	- 论文里面写了一个例子。给一个 4KB 的 全a文件写8KB的b字符。
 		- 先分配一个4K空页
 		- fill 0-4l

pages/hls__XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.md

@@ -1,13 +1,80 @@
 file:: [XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf](../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf)
 file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1682647057931_0.pdf
 
+- 总结
+	- 问题：IPC很慢，而微内核需要用到大量的IPC来完成系统功能
+	- 相关工作：软件优化还是避免不了trap开销、或者是有一些并发问题；硬件优化需要大规模修改软件。
+	- 场景：微内核Zircon和seL4、Android Binder
+	- IPC分析：两个主要的开销，domain switch 和 message copy
+		- 在seL4中的一次IPC有几个主要的步骤：Trap-Restore、IPC logic、Process switch、Message transfer
+			- Trap Restore：caller陷入内核然后加载callee执行
+			- IPC logic：检查权限并选择消息传递策略（fast/slow path
+			- Process switch：线程调度、完成消息传递、权限设置
+			- Message transfer：三种方法，reg、buffer、共享内存
+	- 硬件设计：
+		- 除了`seg-mask`之外,其余所有的寄存器和相关的内存均为user只读,kernel结合硬件来维护这些东西
+		- x-entry
+			- 每个x-entry对应一个IPC server过程,记录页表\Cap bitmap地址\入口地址\Seg list地址\valid
+			- 存放在一个全局的x-entry-table里面，由内核在启动的时候分配。相关的寄存器为`x-entry-table-reg` 和`x-entry-table-size`
+		- x-cap
+			- 硬件实现的capability机制,用于检查一个线程是否可以调用某个IPC过程
+			- 存放在per-thread的XCALL-cap-bitmap里面
+		- linkage
+			- 记录调用信息,返回的时候要用,所有caller的XPC寄存器都保存在这里,存放在per-thread的linkage stack里面,由`link-reg`指定当前线程的stack
+		- relay-seg
+			- 对应连续的物理内存,用于传递消息. 一个进程可以有多个这玩意,对应的映射信息存放在per-address-space的seg-list里面
+			- `seg-reg`对应seg-list中的一个entry,具有比TLB更高的优先级,进行地址翻译
+				- 该寄存器将在调用时被保持
+			- `seg-mask`用来在IPC的时候控制暴露给callee的message的范围
+			- 所有权:内核保证每个relay-seg同一时间只能在一个CPU核心上被使用,也就是两个core上的seg-reg不能一样
+			- 返回检查:在返回的时候要求seg-reg和进入的时候一致
+		- XPC Engine Cache
+			- 软件管理的cache,可以通过预取来优化xcall
+		- 指令
+			- `xcall #reg` 检查cap,加载并检查目标x-entry,压栈linkage record,切换地址空间并跳转,同时将caller的x-cap-reg存进某一个GPR供callee检查
+			- `xret` 出栈linkage recrd,返回caller
+			- `swapreg #reg` 把seg-reg换成seg-list中对应index的东西(或者invalidate它)
+	- 软件移植
+		- 软件接口
+			- `xpc_register( handler, handler_thread, max_xpc_ctx)`
+			- `xpc_return()`
+			- `alloc_relay()`
+			- `xpc_call(server_ID, xpc_arg)`
+		- `grant-cap`: server将访问某个IPC过程的cap赋予给client,因为cap-bitmap只能内核动,所以要打系统调用,然后内核根据server是否有grant-cap来决定它是否有权grant
+		- Split Thread State, scheduling state & runtime state(地址空间和Capabilities), 用 x-cap-reg 来作为线程标识, 需要让内核知道现在是在caller还是在callee
+		- Per-invocation C-Stack, 支持server过程被并发访问,中间加一段代码来选择context.可能会被ddos攻击,需要credit policy控制访问
+		- Application termination: 调用链上的进程在返回之前炸了,需要扫所有进程的link stack然后把炸掉进程的record全部invalidate,这样就会触发异常让kernel处理
+		- Message size negotiation: 预留一些空间给调用链后面的进程用
+		- Message shrink: `seg-mask`
+		- Segment Revocation: 进程终止的时候,扫描该进程的seg-list,把属于caller的还回去以及回收工作
+		- 用XPC实现Android Binder和ashmem
+			- 修改 Binder Driver 和 Binder framework
+			- server注册: ioctl driver 增加xentry
+			- client请求: ioctl driver 赋予xcap
+			- client调用: xcall,用relay-seg实现数据传递
+			- ashmem的allocation(分一个relayseg), map(把VA写进seg-entry), transfer(xcall并传递seg-reg)
+	- 性能
+		- microbenchmark 测试周期数上的优化
+			- 三个部分, trampoline,xcall,TLB
+			- 优化条件: ASID, non-block link stack, xpc cache
+			- same core 和 cross core
+		- OS services 测了 FS 和 Network
+			- 写操作优化比较明显,当然如果软件上有什么减少ipc的buffer那另说
+		- Application 测了 YCSB+Sqlite 和 一个服务器
+			- FS操作多的优化明显,软件内部有cache的就少一些
+		- Android Binder 测了buffer和Ashmem两种方法
+			- 由于没改linux内核,只能用machine mode来前述的问题,外加没有asyncIPC
+			- 测试了binder buffer(但是大小受限)和仅用ashmem两种情况
+		- Generality 在一个arm模拟器上又测了测
 - ABSTRACT
   ls-type:: annotation
   hl-page:: 1
   hl-color:: yellow
   id:: 644b281a-d7fa-4163-8e75-a39d74215bfa
+  collapsed:: true
 	- Motivation: resurgent interest in microkernel, mobile devices
 	- 微内核需要很多的 IPC 来保持隔离性，但是IPC 操作很慢。
+	  collapsed:: true
 		- seL4 single way fast path - 468 cycles; Fuchsia - over 10k round-trip
 		- 相对于宏内核而言，性能差很多
 	- 宏内核也有 IPC 性能问题
@@ -15,6 +82,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
 	  ls-type:: annotation
 	  id:: 645656b2-93db-4a0b-913a-1a3887c51e83
 	  hl-color:: yellow
+	  collapsed:: true
 		- Android application & user-level services
 		- Android Binder 机制：
 			- 一般而言，IPC （比如管道）要先 copy to kernel buffer 再 copy from kernel buffer
@@ -24,6 +92,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
 	  ls-type:: annotation
 	  id:: 645657b7-afa3-47b8-af22-420c1b276d2e
 	  hl-color:: yellow
+	  collapsed:: true
 		- 上下文切换有很多指令的overhead
 		- 共享内存有安全问题，TOCTTOU
 		- 页表重映射会导致TLB 大量miss
@@ -32,6 +101,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
 	  hl-page:: 2
 	  hl-color:: yellow
 	  id:: 645658e6-082b-4c9c-90f1-cf172fe91328
+	  collapsed:: true
 		- Software 还是要 trap
 		- Hardware 用 tagged memory 代替页表来减少 switch 的耗时，但是内核要大改
 	- The design has four goals:
@@ -39,12 +109,14 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
 	  hl-page:: 2
 	  hl-color:: yellow
 	  id:: 645658a9-a477-47cf-bad2-7a5b4bd91683
+	  collapsed:: true
 		- 不 trap、0拷贝、kernel 小改、hardware 小改
 	- new primitive contains three parts
 	  ls-type:: annotation
 	  hl-page:: 2
 	  hl-color:: yellow
 	  id:: 645658bc-32e3-476b-a1b1-0f3540268e3f
+	  collapsed:: true
 		- new hardware-aware abstraction, x-entry
 		  ls-type:: annotation
 		  hl-page:: 2
@@ -65,12 +137,13 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
 		  ls-type:: annotation
 		  id:: 64565ae6-b80f-4f0b-b738-fc79efc17aeb
 		  hl-color:: yellow
-			- ownership transfer for TOCTOU, no TLB flush, handover in invoking chain
+			- ownership transfer against TOCTOU, no TLB flush, handover in invoking chain
 	- synchronous IPC
 	  ls-type:: annotation
 	  hl-page:: 2
 	  hl-color:: yellow
 	  id:: 64565b4b-aa86-4c99-a02a-9fff0d9d0dd0
+	  collapsed:: true
 		- 解决了低 throughput 和难用的多线程模型
 		  hl-page:: 2
 		  ls-type:: annotation
@@ -81,16 +154,20 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
 		  ls-type:: annotation
 		  id:: 64565b7c-f2d8-49fe-b6a6-8fdc275c1e75
 		  hl-color:: yellow
+			- 大概看了原论文，基本的理念和这里的XPC差不多，意思应该是让RPC对内核可见，然后RPC的时候内核不会把client给block掉，而是让client线程执行server的代码，只需要切换一部分寄存器和一部分的地址空间。（作者说类似于 syscall，也有点道理）
+			- 感觉这篇也就是给这个什么 migrating model 加了硬件支持
 - 2 MOTIVATION
   ls-type:: annotation
   hl-page:: 2
   hl-color:: yellow
   id:: 64565a29-7ced-4d34-8580-fe584783a35b
+  collapsed:: true
 	- 2.1 IPC Performance is Still Critical
 	  ls-type:: annotation
 	  hl-page:: 2
 	  hl-color:: yellow
 	  id:: 64565d37-df65-4458-b1f2-838473637201
+	  collapsed:: true
 		- 测试：YCSB（workload generator for benchmarking KV stores）， seL4，SQLite3
 		- IPC 占用了 20-40% 的时间
 		- IPC 过程中，大概一半的时间在复制数据，当然对于短IPC，大部分时间在 ctx switch（这个时间基本上是固定的）
@@ -171,6 +248,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
 	  hl-page:: 3
 	  hl-color:: yellow
 	  id:: 6456687d-1f7b-4918-942f-78a3c66bdad3
+	  collapsed:: true
 		- 有很多的 `x-entry` 记录可 IPC 的 procedure，然后有一个ID作为它在表里面的 Index
 		  hl-page:: 3
 		  ls-type:: annotation
@@ -184,6 +262,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
 	  hl-page:: 4
 	  hl-color:: yellow
 	  id:: 64566b0b-9fd9-474f-aeea-aa032fbca2d5
+	  collapsed:: true
 		- 一个 `relay-seg` 是一块 ==物理连续== 的内存
 		- 内存地址翻译通过新的 reg `seg-reg` 完成，同时`seg-reg`在 caller 和 callee 之间传递，因此 callee 可以直接访问
 			- OS 需要保证这块物理地址不会被常规的页表映射占用
@@ -256,11 +335,13 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
   hl-page:: 5
   hl-color:: yellow
   id:: 64565fc3-b632-4cb5-949e-3f96d9ce5f2f
+  collapsed:: true
 	- relay-seg
 	  ls-type:: annotation
 	  hl-page:: 5
 	  hl-color:: yellow
 	  id:: 64567cca-6189-4008-a36e-f04ddfcdbd8c
+	  collapsed:: true
 		- add a register `seg-reg` = `VA | PA | Len | Perm`
 		- prior to TLB, direct-map VA to PA (contiguous physical memory)
 		- `relay-seg` 指的是一块内存，而 `seg-reg` 表示的是一个映射
@@ -269,6 +350,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
 	  hl-page:: 5
 	  hl-color:: yellow
 	  id:: 64567cc7-b245-4d66-8d32-6c9dec52f0d7
+	  collapsed:: true
 		- 设计者不希望用户程序直接修改 `seg-reg` 的映射，因此加了一个`seg-mask` 用来把当前进程的 `seg-reg` 切出来一部分再传递
 		- 主要是用来 invoking chain 的，可能是作者认为这种情况比较常见吧
 	- Multiple relay-segs
@@ -296,7 +378,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
 	  hl-color:: yellow
 	  id:: 64570679-5acf-4701-b718-f1d3b22d3df7
 		- 硬件保证 `seg-reg` 在 `xret` 的时候和存在 `linkage-record` 里面的是一致的
-		- 奇妙的安全检查机制
+		- 因为如果callee是恶意软件,那它可能会把一个别的seg-reg给塞给caller,如果caller不检查可能会出问题. 因为seg-reg好像只能软件改
 	- emmm，它好像没说怎么创建这些东西的接口？
 - 4 IMPLEMENTATION
   ls-type:: annotation
@@ -308,6 +390,7 @@ file-path:: ../assets/XPC_Architectural_Support_for_Secure_and_Efficient_Cross_1
   hl-page:: 5
   hl-color:: yellow
   id:: 64571250-753f-4f6c-b402-926ef4594c06
+  collapsed:: true
 	- XPC Engine 
 	  ls-type:: annotation
 	  hl-page:: 5