My question is just for curiosity, I'm not a developer of MacOS Thunderbolt drivers so I have no experience with that.
I've come across this page about thunderbolt drivers and IOMMU on MacOS. From what I've understood, when the driver asks for a memory address, the address obtained is not physical but it is a virtual address mapped by the IOMMU. I think this is due to the security risks of using DMA without a IOMMU. However there are some option for a driver to bypass remapping, for example calling an IODMACommand
object’s initWithSpecification
method with mappingOptions
set to kBypassed
. However in the page it is said that calling a method like that to obtain an unmapped physical address and use that for DMA will break the driver.
So my question is: in a thunderbolt driver, what's the purpose of asking for unmapped physical address if that address cannot be used for DMA?
Sorry if this question may seem dumb, but like I said I've no experience with this kind of stuffs, I'm just very curious.
What's the purpose of bypassing remapping in Thunderbolt driver?
230 views Asked by namerand At
1
There's really no reason to do this in a Thunderbolt driver because as you say the Thunderbolt device only gets to "see" addresses in the IOMMU's virtual address space.
You'd use unmapped addresses if you were writing a driver for something that interfaces with system memory using real physical addresses from the perspective of the CPU. There's not much opportunity for 3rd party developers to do this type of thing on a real Mac, but when writing drivers for (para-)virtualised "hardware" in VMs, or presumably, when writing drivers for Hackintoshes, there are certainly situations where you're talking to a real or virtual device or service which is not "behind" an IOMMU - usually, this means anything not on any PCIe bus.
For example, I used the
kIOMemoryMapperNone
option toIOMemoryDescriptor:: getPhysicalSegment()
in my driver for the Virtio memory balloon. The memory balloon device is really some code on the VM host which operates on VM-CPU-physical page addresses, so if there's a (virtualised) IOMMU in the virtual machine system, sending the memory balloon "mapped" physical addresses would not have the intended result.