绕过Thunderbolt驱动程序中的重新映射的目的是什么？

问题描述

我的问题只是出于好奇，我不是MacOS Thunderbolt驱动程序开发人员，因此我对此没有经验。
我在this页面上看到了有关MacOS上的雷电驱动程序和IOMMU的信息。据我了解，当驱动程序要求一个内存地址时，获得的地址不是物理地址，而是IOMMU映射的虚拟地址。我认为这是由于使用不带IOMMU的DMA带来的安全风险。但是，驱动程序有一些绕过重新映射的选项，例如，将IODMACommand设置为initWithSpecification的{​​{1}}对象的mappingOptions方法。但是，在该页面中，据说调用这样的方法来获取未映射的物理地址并将其用于DMA将破坏驱动程序。
所以我的问题是：在一个雷电驱动程序中，如果该地址不能用于DMA，那么请求未映射的物理地址的目的是什么？
抱歉，这个问题似乎很愚蠢，但是就像我说的那样，我对这种东西没有经验，我很好奇。

解决方法

真的没有理由在Thunderbolt驱动程序中执行 ，因为正如您所说的，Thunderbolt设备只能“看到” IOMMU虚拟地址空间中的地址。

如果从CPU的角度来看，要使用 real 物理地址为与系统内存接口的设备编写驱动程序，则将使用未映射的地址。第三方开发人员在真正的Mac上进行此类操作的机会不多，但是在VM中为（半）虚拟化“硬件”编写驱动程序时，或者大概在为Hackintoshes编写驱动程序时，肯定会遇到这种情况与不在IOMMU后面的真实或虚拟设备或服务进行通信-通常，这意味着任何PCIe总线上都没有任何东西。

例如，在我的Virtio内存气球驱动程序中的I used the kIOMemoryMapperNone option to IOMemoryDescriptor:: getPhysicalSegment()。内存气球设备实际上是VM主机上运行在VM-CPU物理页面地址上的某些代码，因此，如果虚拟机系统中有一个（虚拟的）IOMMU，则发送内存气球“映射”的物理地址将不会预期的结果。