GitLab

The iommu is enabled by default when xen is booting and later disabled
in iommu_setup() when no iommu is present.

But under some circumstances iommu code can be called before
iommu_setup() is processed. If there is no iommu available xen crashes.

This can happen for example when panic(...) is called as introduced
with the patch "x86-64: detect processors subject to AMD erratum #121
and refuse to boot" since xen 4.1.3, resulting in
find_iommu_for_device() to be called in the context of
disable_IO_APIC() / __stop_this_cpu().

This patch fixes this by keeping the iommu disabled until iommu_setup()
is entered.
Originally-by: Ronny Hegewald <ronny.hegewald@online.de>

In order for iommu_enable to be off initially, iommu_supports_eim()
must not depend on it anymore, nor must acpi_parse_dmar(). The former
in turn requires that iommu_intremap gets uncoupled from iommu_enabled
(in particular, failure during IOMMU setup should no longer result in
iommu_intremap getting cleared by generic code; IOMMU specific code
can still do so provided in can live with the consequences).

This could have the nice side effect of allowing to use "iommu=off"
even when x2APIC was pre-enabled by the BIOS (in which case interrupt
remapping is a requirement, but DMA translation [obviously] isn't), but
that doesn't currently work (and hence x2apic_bsp_setup() forces the
IOMMU on rather than just interrupt remapping).

For consistency with VT-d, make the AMD IOMMU code also skip all ACPI
table parsing when neither iommu_enable nor iommu_intremap are set.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
Acked-by: "Huang2, Wei" <Wei.Huang2@amd.com>