yuguorui96

@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

纯粹应付面试完全没必要，也确实无法深入。真是有兴趣可以写个 demo 驱动，解决问题才能深入结构。

也可能是是内核有内存泄露，我写过这样的 bug……

@bthulu 有的，云盒，云展，专有云。

数据上云场景： https://www.alibabacloud.com/help/zh/doc-detail/51655.htm

或者直接上传到 OSS 上。