Give the Qualcomm Snapdragon X Elite (X1E80100) the same treatment as its
predecessors and don't touch the SMMUv2.

ok kettenis@

Disable smmu(4) for Qualcomm SC8280XP on FDT attachment like we already do
on ACPI.

ok kettenis@

constify struct cfattach

While it seems like we can choose any I/O virtual address for peripheral
devices, this isn't really the case. It depends on the bus topology of
how devices are connected. In the case of PCIe, devic

While it seems like we can choose any I/O virtual address for peripheral
devices, this isn't really the case. It depends on the bus topology of
how devices are connected. In the case of PCIe, devices are assigned
addresses (in PCI BARs) from the PCI address spaces. Now if we take an
address from one of these address spaces for our IOVA, transfers from
from a PCI device to that address will terminate inside of the PCI bus.
This is because from the PCI buses' point-of-view, the address we chose
is part of its address space. To make sure we don't allocate addresses
from there, reserve the PCI addresses in the IOVA.

Note that smmu(4) currently gives each device its own IOVA. So the PCI
addresses will be reserved only in IOVA from PCI devices, and only the
addresses concerning the PCI bus it is connected to will be reserved.
All other devices behind an smmu(4) will not have any changes to their
IOVA.

ok kettenis@

show more ...

Change API of acpiiort(4). It was written as a hook before, taking the
PCI attach args and replacing the DMA tag inside. Our other IOMMU API
though takes a DMA tag and returns the old one or a new

Change API of acpiiort(4). It was written as a hook before, taking the
PCI attach args and replacing the DMA tag inside. Our other IOMMU API
though takes a DMA tag and returns the old one or a new one. To have
acpiiort(4) integrate better with non-PCI ACPI devices, change the API
so that it is more similar to the other API. This also makes the code
easier to understand.

ok kettenis@

show more ...

Instead of sprinkling the device's DMA tag, always return a new DMA tag
which is based on the IOMMU's. If you think about it, using the IOMMU's
DMA tag makes more sense because it is the IOMMU that

Instead of sprinkling the device's DMA tag, always return a new DMA tag
which is based on the IOMMU's. If you think about it, using the IOMMU's
DMA tag makes more sense because it is the IOMMU that does the actual DMA.
Noticed while debugging, since the SMMU's map function was called twice:
once for the PCI device, and once for its ppb(4). As the transaction has
the PCI device's Stream ID, not the ppb(4)'s, this would be useless work.

Suggested by kettenis@

show more ...

Add smmu(4), a driver the ARM System MMU. This IOMMU is basically a
regular ARM CPU MMU re-used for I/O devices. Implementations can have a
mix of stage-2 only and stage-2/stage-2 context blocks (d

Add smmu(4), a driver the ARM System MMU. This IOMMU is basically a
regular ARM CPU MMU re-used for I/O devices. Implementations can have a
mix of stage-2 only and stage-2/stage-2 context blocks (domains). The
IOMMU allows different ways of grouping devices into a single domain.

This implementation only supports SMMUv2, since there is basically
no relevant SMMUv1 hardware. It also only supports AArch64
pagetables, the same as our pmap. Hence lots of code was taken from
there. There is no support for 32-bit pagetables, which would have
also been needed for SMMUv1 support. I have not yet seen any
machines with SMMUv3, which will probably need a new driver.

There is some work to be done, but the code works and it's about
time it hits the tree.

ok kettenis@

show more ...