Re: git: 0f5116d7efe3 - main - AMD IOMMU driver

From: Mark Johnston <markj_at_freebsd.org>
Date: Sun, 03 Nov 2024 15:39:50 UTC
On Sat, Nov 02, 2024 at 11:46:40PM +0000, Konstantin Belousov wrote:
> The branch main has been updated by kib:
> 
> URL: https://cgit.FreeBSD.org/src/commit/?id=0f5116d7efe33c81f0b24b56eec78af37898f500
> 
> commit 0f5116d7efe33c81f0b24b56eec78af37898f500
> Author:     Konstantin Belousov <kib@FreeBSD.org>
> AuthorDate: 2024-05-12 10:20:11 +0000
> Commit:     Konstantin Belousov <kib@FreeBSD.org>
> CommitDate: 2024-11-02 23:45:40 +0000
> 
>     AMD IOMMU driver
>     
>     This driver is functionally equivalent to the in-tree Intel DMAR code.
>     It handles busdma and interrupt remapping from the host OS.  There is no
>     integration with bhyve, and the stub iommu drivers in bhyve code cannot
>     coexist with this driver (planned).
>     
>     The biggest architectural problem with the code is that the AMD IOMMU
>     units are enumerated as PCIe-attached security devices, which is much
>     later after HPET and IOAPIC drivers attached and actived interrupts.
>     Because of this, HPET FSB interrupts and IOAPIC interrupts are always
>     identity-mapped.
>     
>     The code is of late alpha quality.  By default the driver is disabled.
>     To enable for testing, set in loader.conf:
>     hw.amdiommu.enable=1
>     hw.iommu.dma=1 <- to enable iommu busdma
>     hw.iommu.ir=1 <- to enable interrupt remapping
>     
>     Discussed with: emaste
>     Sponsored by:   Advanced Micro Devices (AMD)
>     Sponsored by:   The FreeBSD Foundation
>     MFC after:      1 week
>     Differential revision:  https://reviews.freebsd.org/D47256

This appears to break loading of vmm.ko, as sys/amd64/vmm/amd/amdiommu.c
already defines a driver called "amdiommu".  Perhaps the module in vmm
should be renamed to amdviiommu or so?