yuguorui96

The hard way is usually the right way.

没有简单的方法，你需要理解当前的 feature 的工作原理，并评估当前 feature 的依赖依赖是否完备。
当依赖不完备是你需要考虑：是否需要引入新的 upstream patch ，还是用老的 API 实现 feature 所需要的逻辑等；
实现过程中可能还需要你不断迭代，直至你找齐所有的拼图。

邮件列表是一个参考，而不是一个答案。如何能根据快速的评估所需要的 patch 是你“不可替代”的要素之一。

@amiwrong123 你再看看上个回答？谜底就在谜面上。

愚以为直接存基址的话，在 32 和 64 之间就需要不同的大小来操作 ldt ，这个非常痛苦。
所以我理解 selector 的本质作用就是替换掉变长的地址宽度。

与其禁止 IPv6 ，不如让 IPv6 能正常处理。

可以试试： https://github.com/yuguorui/rfor

@ins0mn1a 你这里 post 出来的代码我还没看，但是大体上的逻辑是：
1. firmware 需要在启动时默认启用 IOMMU remapping ，然后后续的 DMA 请求就被默认禁止了；
2. 后面 firmware/OS 就可以根据需求更新 IOMMU 的 second-level page table 以允许 /吊销设备的 DMA 访问能力。

是否也就意味着该设备不会受到 IOMMU 的保护呢？
====================================
否

这里的细节很多，可以参考： https://www.intel.com/content/dam/develop/external/us/en/documents/intel-whitepaper-using-iommu-for-dma-protection-in-uefi-820238.pdf

说的更明白点，如果我是一个已经挂载在总线上的恶意设备，如果我不主动暴露 DMA 能力，没啥好方法探测。

如果你的假设是设备都是诚实的，倒是可以翻翻驱动，看看驱动分配时有没有用 DMA 相关的内存分配 API ，但是这个都只是启发式的。

设备支持不支持 DMA 和驱动没有必然联系。

一个设备有 DMA 控制器，能朝系统总线上写 DMA 相关的消息就可以进行 DMA 了（假设我不关心会不会把系统写挂）。以 PIC 为例，DMA 的过程实际就是写 TLP 包的过程，然后就可以通过 PCI 的路由逻辑路由到 DIMM 里了，这个过程和任何驱动有关吗？

@yuguorui96 额，后面的时间写反了，zlib 是快的那个哈。

写 1 亿没意思，连磁盘缓存都没打满……写个 10 亿吧
即使是随机数据，使用 zlib 这样的库也能极大的压缩数据

1e8, zlib vs raw, 810ms vs 310 ms
1e9, zlib vs raw, 11s vs 3.73s

https://gist.github.com/yuguorui/9700aa236dcb6e7072de282310d3b866