drivers/iommu/intel/dmar.c
Source file repositories/reference/linux-study-clean/drivers/iommu/intel/dmar.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/iommu/intel/dmar.c- Extension
.c- Size
- 63723 bytes
- Lines
- 2395
- Domain
- Driver Families
- Bucket
- drivers/iommu
- Inferred role
- Driver Families: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/pci.hlinux/dmar.hlinux/iova.hlinux/timer.hlinux/irq.hlinux/interrupt.hlinux/tboot.hlinux/dmi.hlinux/slab.hlinux/iommu.hlinux/numa.hlinux/limits.hasm/irq_remapping.hiommu.h../irq_remapping.h../iommu-pages.hperf.htrace.hperfmon.h
Detected Declarations
struct dmar_res_callbackenum faulttypefunction dmar_register_drhd_unitfunction dmar_free_dev_scopefunction dmar_alloc_pci_notify_infofunction dmar_free_pci_notify_infofunction dmar_match_pci_pathfunction dmar_insert_dev_scopefunction for_each_dev_scopefunction dmar_remove_dev_scopefunction for_each_active_dev_scopefunction dmar_pci_bus_add_devfunction for_each_drhd_unitfunction dmar_pci_bus_del_devfunction vf_inherit_msi_domainfunction dmar_pci_bus_notifierfunction device_to_iommufunction dmar_find_dmarufunction dmar_parse_one_drhdfunction dmar_free_drhdfunction dmar_parse_one_anddfunction dmar_parse_one_rhsafunction dmar_table_print_dmar_entryfunction dmar_table_detectfunction dmar_walk_remapping_entriesfunction dmar_walk_dmar_tablefunction parse_dmar_tablefunction dmar_pci_device_matchfunction dmar_find_matched_drhd_unitfunction dmar_acpi_insert_dev_scopefunction for_each_drhd_unitfunction for_each_dev_scopefunction dmar_acpi_dev_scope_initfunction dmar_dev_scope_initfunction for_each_pci_devfunction dmar_register_bus_notifierfunction dmar_table_initfunction warn_invalid_dmarfunction dmar_validate_one_drhdfunction detect_intel_iommufunction unmap_iommufunction map_iommufunction alloc_iommufunction free_iommufunction reclaim_free_descfunction qi_dump_faultfunction qi_check_faultfunction interface
Annotated Snippet
struct dmar_res_callback {
dmar_res_handler_t cb[ACPI_DMAR_TYPE_RESERVED];
void *arg[ACPI_DMAR_TYPE_RESERVED];
bool ignore_unhandled;
bool print_entry;
};
/*
* Assumptions:
* 1) The hotplug framework guarentees that DMAR unit will be hot-added
* before IO devices managed by that unit.
* 2) The hotplug framework guarantees that DMAR unit will be hot-removed
* after IO devices managed by that unit.
* 3) Hotplug events are rare.
*
* Locking rules for DMA and interrupt remapping related global data structures:
* 1) Use dmar_global_lock in process context
* 2) Use RCU in interrupt context
*/
DECLARE_RWSEM(dmar_global_lock);
LIST_HEAD(dmar_drhd_units);
struct acpi_table_header * __initdata dmar_tbl;
static int dmar_dev_scope_status = 1;
static DEFINE_IDA(dmar_seq_ids);
static int alloc_iommu(struct dmar_drhd_unit *drhd);
static void free_iommu(struct intel_iommu *iommu);
static void dmar_register_drhd_unit(struct dmar_drhd_unit *drhd)
{
/*
* add INCLUDE_ALL at the tail, so scan the list will find it at
* the very end.
*/
if (drhd->include_all)
list_add_tail_rcu(&drhd->list, &dmar_drhd_units);
else
list_add_rcu(&drhd->list, &dmar_drhd_units);
}
void *dmar_alloc_dev_scope(void *start, void *end, int *cnt)
{
struct acpi_dmar_device_scope *scope;
*cnt = 0;
while (start < end) {
scope = start;
if (scope->entry_type == ACPI_DMAR_SCOPE_TYPE_NAMESPACE ||
scope->entry_type == ACPI_DMAR_SCOPE_TYPE_ENDPOINT ||
scope->entry_type == ACPI_DMAR_SCOPE_TYPE_BRIDGE)
(*cnt)++;
else if (scope->entry_type != ACPI_DMAR_SCOPE_TYPE_IOAPIC &&
scope->entry_type != ACPI_DMAR_SCOPE_TYPE_HPET) {
pr_warn("Unsupported device scope\n");
}
start += scope->length;
}
if (*cnt == 0)
return NULL;
return kzalloc_objs(struct dmar_dev_scope, *cnt);
}
void dmar_free_dev_scope(struct dmar_dev_scope **devices, int *cnt)
{
int i;
struct device *tmp_dev;
if (*devices && *cnt) {
for_each_active_dev_scope(*devices, *cnt, i, tmp_dev)
put_device(tmp_dev);
kfree(*devices);
}
*devices = NULL;
*cnt = 0;
}
/* Optimize out kzalloc()/kfree() for normal cases */
static char dmar_pci_notify_info_buf[64];
static struct dmar_pci_notify_info *
dmar_alloc_pci_notify_info(struct pci_dev *dev, unsigned long event)
{
int level = 0;
size_t size;
struct pci_dev *tmp;
struct dmar_pci_notify_info *info;
Annotation
- Immediate include surface: `linux/pci.h`, `linux/dmar.h`, `linux/iova.h`, `linux/timer.h`, `linux/irq.h`, `linux/interrupt.h`, `linux/tboot.h`, `linux/dmi.h`.
- Detected declarations: `struct dmar_res_callback`, `enum faulttype`, `function dmar_register_drhd_unit`, `function dmar_free_dev_scope`, `function dmar_alloc_pci_notify_info`, `function dmar_free_pci_notify_info`, `function dmar_match_pci_path`, `function dmar_insert_dev_scope`, `function for_each_dev_scope`, `function dmar_remove_dev_scope`.
- Atlas domain: Driver Families / drivers/iommu.
- Implementation status: integration implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.