On Fri, 13 Jul 2012 13:07:04 +0200 Sebastian Sumpf (SS) wrote:
SS> Okay the ACPI driver seems definitely necessary here. Since the device SS> IRQs (10/11) are overwritten (to GSI 16/18) by the driver. So far so SS> good, what is really weird is that the drivers seems to read strange SS> values in the IOMMU case.
When the IOMMU is active, DMA requests and interrupts are restricted by the NOVA microhypervisor. Device drivers need to follow certain guidelines, see below.
SS> @Alexander Boettcher: Is there anything to consider regarding I/O memory SS> when using Nova with enabled IOMMU?
With the IOMMU active, a user-level device driver must specify which memory regions of its PD are DMA-able. This is done by setting the D-bit in the Delegate Transfer Item. All memory mappings where the D-bit is not set will not be DMA-able (unless the IOMMU is inactive). My recommendation is that device drivers map their own code and private non-DMA-able and only allow DMA transfers to I/O buffer regions.
Also, when the IOMMU is active, the addresses programmed into DMA transfers must be host-virtual addresses. This alleviates device drivers from having to know physical memory addresses. They can DMA into their virtual address space. In contrast, when the IOMMU is inactive, the addresses in DMA transfers must be host-physical addresses.
An active IOMMU will only let interrupt vectors through that have been explicitly whitelisted by the hypervisor. Applications request an interrupt by means of the assign_gsi hypercall and also specify which CPU they want the interrupt routed to. This must be done for any interrupt (IOAPIC or MSI). (I'm thinking about adding some code to the hypervisor, causing sem_down to fail on an interrupt semaphore unless the interrupt has been configured using assign_gsi.)
Failure to whitelist a DMA region or interrupt vector will result in a diagnostic message printed to the hypervisor console when the IOMMU aborts a transaction.
Let me know if there are further questions related to the IOMMU.
Cheers, Udo