IOMMU (was: USB HID driver fails to recognize input devices)
Udo Steinberg
udo at ...121...
Wed Jul 18 22:10:17 CEST 2012
On Wed, 18 Jul 2012 21:34:24 +0200 Norman Feske (NF) wrote:
NF> I am just wondering: If DMA addresses are host-virtual addresses and
NF> there are multiple processes running, how does the IOMMU know which
NF> virt-to-phys translation to use? I can loosely remember that you once
NF> told me that devices must be associated with PDs. Is this correct? If
NF> so, how does a driver PD express to the hypervisor that it deals with
NF> a certain device?
You can bind a device to a PD using the assign_pci hypercall. Once bound,
the device uses the DMA-able part of the memory space of that PD. If you
don't bind the device, it will only work with the IOMMU being inactive.
NF> Currently, this function is meaningful only on ARM on Fiasco.OC. But
NF> it looks like a good way to handle the D-bit on NOVA without the need
NF> of any special precautions at the driver side. Because core is the
NF> pager of the driver, it could always map DMA buffers (and only those)
NF> with the D-bit set.
Right.
NF> > Also, when the IOMMU is active, the addresses programmed into DMA
NF> > transfers must be host-virtual addresses. This alleviates device
NF> > drivers from having to know physical memory addresses. They can DMA
NF> > into their virtual address space. In contrast, when the IOMMU is
NF> > inactive, the addresses in DMA transfers must be host-physical
NF> > addresses.
NF>
NF> Is the use of virtual addresses mandatory? If so, the driver must be
NF> aware of the presence of the IOMMU, doesn't it? It would be nice to
NF> find a way of using the IOMMU in a way that is transparent to the driver.
The memory space of a PD consists of three subspaces.
1) The host page table translates host-linear to host-physical addresses
2) The guest page table translates guest-physical to host-physical addresses
3) The DMA page table translates DMA addresses to host-physical addresses
When you delegate memory
* all mappings to into subspace 1) (unless they target the hypervisor region)
* mappings with G-bit additionally go into 2)
* mappings with D-bit additionally go into 3)
It follows that subspaces 2) and 3) are a subset of subspace 1) and also
that guest-physical address = host-virtual address = DMA address.
This has a number of benefits: If a device is directly assigned to a
guest, the guest will obviously program guest-physical addresses into its
DMA transfers, and the IOMMU will translate to host-physical. Likewise, a
host device driver is expected to program a host-virtual address into its
DMA transfers, which the IOMMU will translate into host-physical the very
same way. Also, guest-physical memory of a VM is equivalent to host-virtual
memory of the VMM, which allows the VMM easy access to its VM.
So yes, the device driver must know if the IOMMU is active or not, and it
must choose the right type of address for DMA transfers. NUL tries to assign
a device to a PD: if that fails, it assumes the IOMMU is inactive and uses
host-physical addresses; if that succeeds, it uses host-virtual addresses.
Cheers,
Udo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20120718/83017840/attachment.sig>
More information about the users
mailing list