进程直接IO访问，要求物理内存一直驻留在进程的虚拟地址上，即要求物理内存钉在进程指定的虚拟地址上。IB uverbs模块通过get_user_pages()和put_page()来实现钉住物理内存和解绑的需求，并且用进程pinned_vm变量对钉住的物理内存计数，从而确保进程钉住的物理内存不会超过RLIMIT_MEMLOCK的限制。IB uverbs模块是基于Linux字符设备驱动框架下实现的，所有IB资源的创建和销毁都是通过文件描述符的命令实现，内核负责记录给到指定进程上下文的资源。

简单引用计数最好用g_atomic_ref_count而不是用 g_atomic_int_inc() 和g_atomic_int_dec_and_test()；通过这些API访问的整型变量和指针变量，操作时要小心，每个原子操作访问的同一变量内存区域必须保持一致。宏的名称含有“int”就表示对gint和gunit的指针进行操作，宏的名称含有“pointer”就表示对指向guintptr指针变量的指针进行操作。使用这些API编程，不再需要使用请求/释放、或者生产者/消费者的内存屏障。

/pinctrl驱动名称。) //pin描述符数组长度，即pin数量。//pin描述符数组长度，即pin数量。//pinmux操作向量表，如果本驱动支持pin复用操作。//pinctrl操作向量表，用于支持pin分组等全局操作。//pinconf操作向量表，如果本驱动支持pin配置操作。//pin编号，即pinctrl驱动范围内的唯一编号。

一组线程称为进程，一个进程内的所有线程通过共享内存来通信。优点是，共享变量/内存通信非常方便；缺点是，多线程程序对程序员编程能力要求很高，否则很容易发生莫名其妙的BUG。多线程就是为并行而设计的，因此程序员不能对线程之间的执行顺序做任何假定；多线程执行的顺序性必须通过在程序代码中的同步原语来直接保证。GLib库设计多线程函数的目标之一是，提高多线程编程的可移植性。

不相关的事件源组可以被不同的线程处理，每个事件源关联一个GMainContext。虽然一个GMainContext只能运行在一个线程之中，而事件源可以在其他线程中注册或注销。主事件循环机制（MEL：the Main Event Loop)在GLib和GTK应用中管理可用的事件源。事件源的类型包括：文件描述符（管道、套接字和常规文件）和定时器超时。每个事件源都有一个优先级。优先级越高，数值越小。优先级高的事件源可以获得优先处理。空闲函数，可以注册到GMainContext，也被分配一个优先级数值。

对应的AKey表项包含了该虚拟地址所属的SDXI功能部件接口的设备号（如果硬件以PCIe设备方式实现SDXI，那么设备号就是总线号/设备号/功能号BDF）和Pasid。当描述符中的AKey索引为0时，该描述符对应的SDXI功能部件接口既是操作发起者，又是数据访问者，零值AKey对应VA就在描述符所有在地址空间。//////////////////下图给了作为PCIe设备，SDXI发送DMA操作的地址转换原理//////////////////SDXI功能部件接口可以既是操作发起者，同时也可以是数据访问者。

我的理解是，SDXI硬件在实现描述符要求的操作是否能以原子操作方式实现。SDXI功能部件完成操作后，将描述符完成情况（完成或相关错误）反馈到/填写到完成状态块。除了统一的框架性内容，还有一个区域就是52位的operation域，针对具体的TYPE和SUBTYPE来定义的。TYPE和SUBTYPE：定义操作组类型（11位）和操作组内的一个操作类型（8位）。ER：1位的错误标记，如果为1，表示至少有一个已经完成的描述符存在错误。这里的地址是指数据缓冲区的内存属性，即描述符操作的内存属性。

2002年10月Linux内核实现了RCU同步机制（RCU读-复制的更新）。对竞争对象存在少量写操作而大量读操作的场景下，RCU可以获得很好的可扩展性。传统互斥型的锁原语，完全没有考虑线程的读/写特点；而读写锁机制虽然允许多个读操作可以并行，但写操作依然要求是独占型【即有一个写操作时，不允许其他的读/写操】；但是RCU机制允许一个写操作和多个读操作可以并行执行。

软件必须保证，SDXI功能部件能够对下表内存数据结构的可读/可写操作，也就是说，下面描述的数据结构是由软件在系统主存中进行初始化，SDXI功能部件也可以访问。3）RKey表都是按照4K字节对齐，每条表项长度都是16字节，SDXI只读。4）16字节的CXT_STS必须按照16字节对齐，该结构包含了命令环的读索引，SDXI可读写。2）4K字节长度的CXT_L1表必须按照4K字节对齐，每条表项长度为32字节，SDXI只读。1）4K字节长度的CXT_L2表必须按照4K字节对齐，每条表项长度为8字节，SDXI只读。

PC市场上的CPU和GPU具有不同的地址空间，与此不同的是，低功耗和低成本要求它们能共享内存空间。最初的ARM处理器没有浮点部件，没有复杂的数学指令，没有SIMD，甚至都不支持两个整数类型的除法指令。然而，对于一些感兴趣的议题，我们会提供规范文档的预览通道，这样就能就技术进行公开讨论，我们也会回答讨论中的问题。从体系结构更新的时间周期来看，从某款芯片开始支持一个体系结构到符合该体系结构的最后一款设备之间，也就几年时间。然而，为了解决旧体系结构上的历史遗留错误，就会提出一个新的体系结构。位会自动进行零扩展。

如果计数数值为零，表示对象已经被释放了。然而，真正的问题是，对引用计数的测试和递增如果不能在一个原子操作中实现，那么在这两个操作之间就有可能插入其他操作。对引用计数refcount域进行原子操作，使得上述两个函数可以安全地在多CPU或抢断环境下直接调用，也就是说在这两个环境下，引用计数器的数值总能获得正确的结果。kref机制的函数很简单，在引用对象数据结构内直接包含一个struct kref计数器或struct kref *计数器指针，在引用对象被操作之前调用kref_get函数，引用计数器递增。

但是如果列表比较长，默认超过256项时，一旦检测到有高优先级的实时进程需要执行时，RCU的软中断处理就会将CPU控制权返还给内核调度器，将列表尾部的数据留到krcud线程来处理。清理工作是在软中断上下文中执行的，也就是说，在硬中断之后或在重调度期间【at rescheduling time】才会执行RCU清理工作。更多关于RCU的工作原理，请参考 https://lwn.net/Article/4974和https://lwn.net/Article/37889这两篇讨论，或者参与SCO小组的讨论。

例如，在页长度为4KB的系统中，第一个内存区域的offset为0，第二个内存区域的offset为4096，后面以此类推。UIO可以帮助他们按照标准的方式去实现用户态驱动，而不是让他们自由发挥在内核创造自己的钩UIO很可能会合并到Linux2.6.22中。这部份内核代码实现了一个非常精简的内核模块，主要功能包括：设备的设置，PCI配置空间的访问，中断处理函数的注册。用户空间驱动这个概念已经有很长时间了，这一次有一个补丁版本已经提交到了Linux2.6.22，这个版本的补丁就是UIO。

基于iio_device结构体中的event_write()函数指针，用户空间驱动程序可以对事件设备进行写操作，这样一来，用户驱动程序可以控制内核对中断的响应，以及对中断的屏蔽。但对于某些设备，在用户态实现驱动还存在一些挑战，例如PCI设备就很少有用户态驱动。主要的区别在于，内核态PCI驱动部分会使能PCI设备，并做一些必要的初始化工作。用户态PCI设备驱动真正棘手的还是中断的处理。通过IIO模块提供的文件操作方法，用户空间设备驱动可以对设备内存进行读/写操作，也可以将设备内存直接映射到用户空间。

屏蔽一个共享中断就会关闭该中断连接上的所有设备的中断，而不是仅仅关闭某个特定用户态驱动中断处理程序对应的设备上的中断。这样一来，内核能直到究竟是哪个设备被中断了，也可以对中断进行确认，并通知设备关闭中断。这样做的原因是：内核处理过程对触发中断的设备一无所知，它不能对中断进行确认，也不能关闭中断。与此同时，Michael Raymond描述了另外一种用户态中断机制，即用户级中断ULI【这个机制是在SGI计算机上实现的，Silicon Graphis Inc.是美国的创新技术公司】。原文作者：Corbet。

他指出，驱动程序的代码量占到整个内核的50%左右，驱动程序的BUG却占到整个内核的85%左右。他们要在计划的时间内实现特定功能的内核编程，接口定义比较随意，常常有很多致命的BUG，在开发过程中连常规开发工具都不使用。在需要考虑的众多功能组件当中，中断是最重要的，也是最有挑战性的。关于用户进程注册和响应设备中断，迄今为止还没有一个好的解决方案。例如，某个进程如果希望处理11号中断，该进程就需要打开/proc/irq/11/irq并期望获得该文件的文件描述符【内核态的处理应该是，中断使能然后等待中断发生】；

在2017年Linux存储、文件系统和内存管理会议的第一天早上全体大会上，Glisse发起了一场关于“CPU不可访问的、设备上的内存”的讨论，在GPUs和FPGA的系统中常常会配置这种设备内存。否则，在数据从设备内存回迁时导致系统活锁。GPU和FPGA在访问这些数据结构之前，对应的系统内存单元还需要被钉住（PINed），这样一来，这些数据结构的物理内存单元在被设备访问时就不会被换出。Glisse承认这一点，但是也提到，因为设备可以直接访问系统主存，所以可以允许某些页绝不会迁移到设备上，这也不是什么大问题。

更高级别API的实现要求，CPU和GPU能并行访问数据，而且要保证缓存一致性，因此我们提出HMM机制，还有其他类似功能被提出，例如通过平台硬件。上次我给Linus和Andrew讲到过，将HMM补丁提交到上游社区的需求是，我们希望无论闭源驱动还是开源驱动，除了Mellanox之外HMM还能获得其他真实硬件支持（当前Mellanox还没有采用HMM所有特性）。——按照设备专用格式，创建一个进程CPU页表的影子页表，并保持CPU页表和影子页表的同步（理解：影子页表其实就是GPU页表）。

Gorman建议Andrew Morton在没有可用的设备驱动之前将HMM纳入到-mm分支（-mm分支是Linux内核关于内存管理的专向分支，而不是主线分支），Morton问道，没有设备驱动是否真的会成为阻碍代码合并到上游主分支的原因。为了完全避免此类问题，Gorman建议，HMM使用的内存都用madvise()系统调用标记为MADV_DONTFORK（madvise系统调用是应用程序向内核提出的关于内存块的操作建议，内核使用这些建议信息进行优化）；内核还缺乏足够的信息，因此内存均衡的效果并不理想。

EHCI主机接口寄存器在BAR0所示的PCI MEM地址空间中，主要包括两部分：1）能力寄存器组2）操作寄存器组下面先介绍能力寄存器组CAPLENGTH寄存器，8位只读寄存器，给出了控制寄存器组的偏移量。HCIVERSION寄存器，16位只读寄存器，兼容EHCI的最大和最小版本号，按照BCD编码格式。高8位是最大版本号，低8位是最小版本号。HCSPARAMS结构参数寄存器，32位只读寄存器。HCCPARAMS能力参数寄存器，32位只读寄存器。