#
ce76b8c8 |
| 07-Sep-2022 |
patrick <patrick@openbsd.org> |
On the Lenovo X13s the named components don't have the single mapping flag set, which we so far had expected to be there. This is allowed by the IORT spec. In that case simply make use of the first
On the Lenovo X13s the named components don't have the single mapping flag set, which we so far had expected to be there. This is allowed by the IORT spec. In that case simply make use of the first mapping if there is a single one.
With feedback from and ok kettenis@
show more ...
|
#
3dbfdff0 |
| 31-Aug-2022 |
patrick <patrick@openbsd.org> |
Compare equality of looked up node using pointers instead of strings, as the component name provided in the IORT might be specified in a different way than our ACPI stack would do.
ok kettenis@
|
#
227a6d54 |
| 31-Aug-2022 |
patrick <patrick@openbsd.org> |
Support SMMUv3 IORT nodes as well in the midlayers. This allows IOMMU mappings to reach a future SMMUv3 implementation.
ok kettenis@, mlarkin@
|
#
471aeecf |
| 06-Apr-2022 |
naddy <naddy@openbsd.org> |
constify struct cfattach
|
#
b9702ae5 |
| 26-Nov-2021 |
patrick <patrick@openbsd.org> |
The IORT table usually only contains single mappings. While on the LX2K there is a non-single mapping for the networking subsystem, we don't yet have support for it and apparently Linux has trouble
The IORT table usually only contains single mappings. While on the LX2K there is a non-single mapping for the networking subsystem, we don't yet have support for it and apparently Linux has trouble with it as well. So for now we can remove the code, because it uses an uninitialized variable and there's no easy way to fix it without re-thinking the concept. The code got there in the first place because it's a copy of the same pattern in our other IOMMU code.
ok jsg@
show more ...
|
#
415019ce |
| 25-Jun-2021 |
patrick <patrick@openbsd.org> |
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 ...
|
#
7d187974 |
| 15-Mar-2021 |
patrick <patrick@openbsd.org> |
Add code to acpiiort(4) to look up named components in the IORT and map them. This makes ACPI's call to acpi_iommu_device_map() do work through acpiiort(4).
ok kettenis@
|
#
88933a1f |
| 15-Mar-2021 |
patrick <patrick@openbsd.org> |
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 ...
|
#
ffdeadb5 |
| 28-Feb-2021 |
patrick <patrick@openbsd.org> |
Add acpiiort(4), a driver for the ACPI I/O Remapping Table. This table contains information which IOMMUs we have and how the devices are routed.
ok kettenis@
|