WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/arch/arm64/dev?h=master 2021-04-03T15:59:08Z 2021-04-03T15:59:08Z patrick patrick@openbsd.org 2021-04-03T15:59:08Z urn:sha1:a5eb7f55b9c1dc179deb7da5fa31c6889c73c8ca is that IOVA allocations always have a gap in-between which produces a fault on access. If a transfer to a given allocation runs further than expected we should be able to see it. We pre-allocate IOVA on bus DMA map creation, and as long as we don't allocate a PTE descriptor, this comes with no cost. We have plenty of address space anyway, so adding a page-sized gap does not hurt at all and can only have positive effects. Idea from kettenis@ 2021-04-03T15:10:58Z patrick patrick@openbsd.org 2021-04-03T15:10:58Z urn:sha1:ab86b9020dc7a7e0f5e6f0a183513a03d13d2e53 pointer address. Not allowing this one to be allocated might help find driver bugs, where the device is programmed with a NULL pointer. We have plenty of address space anyway, so excluding this single page does not hurt at all and can only have positive effects. Idea from kettenis@ 2021-03-29T17:04:00Z kettenis kettenis@openbsd.org 2021-03-29T17:04:00Z urn:sha1:14edd68e6a4948d2244829bbd092d21a09e8127c Adjust the region managed by the extend accordingly but avoid the first and last page. The last page collides with the MSI address used by the PCIe controller and not using the first page helps finding bugs. ok patrick@ 2021-03-26T22:55:48Z kn kn@openbsd.org 2021-03-26T22:55:48Z urn:sha1:def7dd08d0e32b362027b34be550101a5e9795f4 The EBADF error is always overwritten for the standby, suspend and hibernate ioctls, only the mode ioctl has it right. Merge the now identical casese while here. OK patrick 2021-03-22T20:34:45Z patrick patrick@openbsd.org 2021-03-22T20:34:45Z urn:sha1:a66e8666dd1e8617ff67e2f516e578445287310a can be removed. The only thing left to implement for smmu(4) to work out of the box with PCIe devices is to reserve the PCIe MMIO windows. Let's see how we can do this properly. 2021-03-22T20:30:21Z patrick patrick@openbsd.org 2021-03-22T20:30:21Z urn:sha1:cc0ede0677b0110958241fb25b9e05031b91a387 typically pass the physical address, however retrieved, to our PCIe controller code. This physical address can in practise be directly given to the PCIe, but it is not a given that the CPU and the PCIe controller are able to use the same physical addresses. This is even more obvious with an smmu(4) inbetween, which can change the world view by introducing I/O virtual addresses. Hence for this it is indeed necessary to map those pages, which thanks to integration with bus_dma(9) works easily. For this we remember the PCI devices' DMA tag in the interrupt handle during the MSI map, so that we can use the smmu(4)-hooked DMA tag to load the physical address. While some systems might prefer to implement "trapping" pages for MSIs, to make sure devices cannot trigger other devices' interrupts, we only make sure the whole page is mapped. Having the IOMMU create a mapping for each MSI is a bit wasteful, but for now it's the simplest way to implement it. Discussed with and ok kettenis@ 2021-03-15T22:56:48Z patrick patrick@openbsd.org 2021-03-15T22:56:48Z urn:sha1:7d1879745e58d276cce68661f4705ef4be18db73 map them. This makes ACPI's call to acpi_iommu_device_map() do work through acpiiort(4). ok kettenis@ 2021-03-15T22:48:57Z patrick patrick@openbsd.org 2021-03-15T22:48:57Z urn:sha1:88933a1fbb282bf7c34e5e40982905026b06c781 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@ 2021-03-11T11:16:54Z jsg jsg@openbsd.org 2021-03-11T11:16:54Z urn:sha1:36fd90dcf1acf2ddb4ef5dbabe5313b3a8d46ee2 2021-03-11T10:40:22Z kettenis kettenis@openbsd.org 2021-03-11T10:40:22Z urn:sha1:f85058421af9c09d571595b9380084d381859d12 ok patrick@