本文探讨了DMA（直接内存访问）的工作原理，包括其如何减轻CPU负担，以及在Xen虚拟化环境中遇到的问题。在Xen中，由于guest OS使用的是虚拟kernel地址而非实际物理地址，直接操控DMA controller变得复杂。解决方案涉及到IOMMU和page grant table，以及Xen对DMA API的具体实现，如修改Linux DMA API和Calgary's Translation Control Entries。文章还讨论了设备分配和常见的问题，如设备驱动的作用、物理地址的确定以及IOMMU在虚拟化中的角色。
注：这篇学习日志的信息主要来自wikipedia [2]，以下讨论稍显零碎，并不成系统，想要系统，请看参考文献原文。谢谢！
地址（address）有两种：
1. on-card device memory (Linux documentation里叫它做 bus memory) （我不太确定在linux doc里的bus memory 是否指的是on-card memory）
2. main memory (physical memory)
于是就需要有一个mapping 的机制，把它们映射起来，也叫做translate 过来。
一个例子是，从memory 的地址传输（transfer）到网卡的buffer 里，然后网卡再把buffer里的数据发送出去，这样来实现网络传输。那么，buffer里就有一个buffer 地址，它是与main memory 地址是不同的，例如main memory 是用64位地址，e.g., 0x1234FFFF5678EEEE, 而buffer 地址只有16位，e.g., 0x5678, 因此，这里需要有一个mapping的机制在起作用。
问题：
1. 如果有mapping, 那是不是说 on-card memory 与 physical memory 的一个duplicate 呢？如何保持它们的同步更新呢？
一、地址种类（address type)
地址（address）有两种：
1. on-card device memory (Linux documentation里叫它做 bus memory) （我不太确定在linux doc里的bus memory 是否指的是on-card memory）
2. main memory (physical memory)
于是就需要有一个mapping 的机制，把它们映射起来，也叫做translate 过来。
一个例子是，从memory 的地址传输（transfer）到网卡的buffer 里，然后网卡再把buffer里的数据发送出去，这样来实现网络传输。那么，buffer里就有一个buffer 地址，它是与main memory 地址是不同的，例如main memory 是用64位地址，e.g., 0x1234FFFF5678EEEE, 而buffer 地址只有16位，e.g., 0x5678, 因此，这里需要有一个mapping的机制在起作用。
问题：
1. 如果有mapping, 那是不是说 on-card memory 与 physical memory 的一个duplicate 呢？如何保持它们的同步更新呢？
二、具体的寻址过程
DMA 主要是分担 CPU 的寻址职责，不用CPU去等待device 和 memory 间的数据传输，因为这种data transfer 很慢。
cpu把这个职责交给了DMA controller。
举个例子，假设CPU 要执行以下四条cpu指令:
i1: INC EX
i2: MOV [0x4363] BX ; 假设BX 里存了 DMA-enabled device 的地址，这条指令就是DEV 里的数据放到 地址为：0x4363 的内存单元中。
最低0.47元/天 解锁文章
1558
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
