|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH v2] xen/amd/iommu: record the IOMMU for alias DeviceIDs
add_ivrs_mapping_entry() marks an alias DeviceID valid and may give it
an interrupt remapping table, but records the IOMMU only for the device
using the alias. If no IVHD entry names the alias DeviceID itself,
amd_iommu_setup_device_table() passes a NULL IOMMU to
amd_iommu_set_intremap_table(), which dereferences it at boot.
Record the IOMMU for the alias too, as was done before the interrupt
remapping rework. Nothing relies on it being NULL: the alias is then
handled like any other DeviceID. Its remapping table is freed on
cleanup and dumped by the 'V' key, a device at the alias DeviceID can
be added instead of failing with -ENODEV, and reserved ranges, already
recorded for the alias as well, are reported once under it. A NULL
check at the crash site instead would leave the alias device table
entry without interrupt remapping.
Fixes: a3713b97e8e1 ("AMD IOMMU: Rework of interrupt remapping")
Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
---
Changes in v2:
- describe the crash precisely, and why nothing relies on the alias
entry's IOMMU being NULL
- add a Fixes tag
xen/drivers/passthrough/amd/iommu_acpi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/xen/drivers/passthrough/amd/iommu_acpi.c
b/xen/drivers/passthrough/amd/iommu_acpi.c
index d118b36d80..d8ff4d24da 100644
--- a/xen/drivers/passthrough/amd/iommu_acpi.c
+++ b/xen/drivers/passthrough/amd/iommu_acpi.c
@@ -104,6 +104,10 @@ static void __init add_ivrs_mapping_entry(
/* Assign IOMMU hardware. */
ivrs_mappings[bdf].iommu = iommu;
+
+ /* Requests using the alias go through the same IOMMU. */
+ if ( !ivrs_mappings[alias_id].iommu )
+ ivrs_mappings[alias_id].iommu = iommu;
}
static struct amd_iommu * __init find_iommu_from_bdf_cap(
--
2.47.3
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |